现代操作系统和硬件支持创建成百上千个线程，但单核同一时刻仅能真正并行执行一个线程；多线程通过时间片轮转实现“伪并行”，实际并发度受限于 cpu 核心数，而可创建数量主要受内存（尤其是栈空间）约束。
在多线程编程中，一个常见误区是将“CPU 核心数”等同于“可创建线程数上限”。实际上：
✅ 可创建线程数远高于核心数：即使只有一颗双核 CPU（如问题中的 2-core 机器），你完全可创建数百甚至数千个线程——操作系统会通过调度器（scheduler）对它们进行时间片轮转（time-slicing），让每个线程轮流获得 CPU 时间。
❌ 但真正“同时执行”的线程数 ≤ 物理核心数（不考虑超线程）：在无超线程（Hyper-Threading）的双核 CPU 上，任意时刻最多只有 2 个线程处于 CPU 执行态（running on CPU）；其余线程处于就绪（ready）、阻塞（blocked，如等待 I/O、锁或 sleep）或终止状态。
举个直观例子：
// Java 中创建 1000 个线程（默认栈大小约 1MB）
for (int i = 0; i < 1000; i++) {
new Thread(() -> {
// 简单任务：计算 + 短暂休眠
int sum = 0;
for (int j = 0; j < 1000; j++) sum += j;
try { Thread.sleep(10); } catch (InterruptedException e) { }
}).start();
}这段代码在双核机器上能成功启动 1000 个线程，但 OS 调度器会动态分配 CPU 时间片——可能某毫秒内线程 A 和 B 正在执行，下一毫秒切换为 C 和 D。这种快速切换营造出“并发执行”的效果，即所谓的 并发（concurrency），而非严格意义上的 并行（parallelism）。
⚠️ 真正的瓶颈通常不是 CPU，而是内存：
每个 Java 线程默认分配约 1MB 栈空间（JVM 参数 -Xss 控制）。1000 个线程 ≈ 1GB 栈内存，再加上堆内存（如 -Xmx2g），极易触发 OutOfMemoryError: unable to create new native thread。
→ 优化方案：合理减小栈大小
# 启动 JVM 时指定更小的线程栈（例如 128KB） java -Xss128k MyApp
或在创建线程时显式指定：
Thread t = new Thread(null, runnable, "worker", 64 * 1024); // 64KB 栈 t.start();
注意：过小的栈（如 32KB）可能导致 StackOverflowError，尤其当线程内存在深度递归或大量嵌套方法调用时。建议结合实际业务逻辑复杂度权衡——高并发 I/O 密集型任务（如 Netty、Web 容器）常使用小栈 + 协程/异步模型，而非盲目扩线程数。
? 总结建议：
- ✅ 普通应用（几十到几百线程）：无需手动调优，默认配置即可，信任 JVM + OS 调度；
- ✅ 高并发场景（>500 线程）：优先评估是否需改用线程池（ThreadPoolExecutor）、异步非阻塞（如 NIO、Project Loom 的虚拟线程）或事件驱动模型；
- ❌ 避免“为多而多”：线程是重量级资源，创建/销毁/上下文切换均有开销；相比盲目增加线程数，优化算法、减少锁争用、提升 I/O 效率往往收益更大。
