java 线程本质上是**并发的**，在多核系统上可自动实现**并行执行**；jvm 本身不区分“并发”与“并行”的语义边界，而是由底层操作系统和硬件协同调度——自 java 1.0 起即保证并发语义，而并行能力取决于运行环境，与 jdk 版本无直接绑定。
在 Java 中，“并发（concurrency）”与“并行（parallelism）”并非互斥概念，而是具有包含关系：并行一定是并发，但并发不一定是并行。
- 并发指多个线程的逻辑执行流存在重叠（interleaved），其事件发生顺序未被严格定义（如 thread1.start() 和 thread2.run() 的实际执行时序不可预测），这是 Java 内存模型（JMM）和 java.lang.Thread API 所保障的核心语义；
- 并行则进一步要求这些线程在物理层面同时执行（simultaneously），通常依赖多 CPU 核心或超线程技术，属于运行时调度结果，而非语言规范强制要求。
Java 自 1996 年发布首个版本起，就明确将 Thread 类设计为支持并发执行的抽象——JVM 规范仅承诺“线程可被独立调度”，并定义了同步、内存可见性等并发原语（如 synchronized、volatile、java.util.concurrent 包）。至于是否真正并行，完全交由底层实现：
✅ 在现代多核 Linux/Windows/macOS 系统上，主流 JVM（HotSpot）通过 pthread（Linux/macOS）或 Windows Thread API 将 Java 线程一对一映射到 OS 级轻量级进程（1:1 模型），由操作系统内核调度器分配至空闲 CPU 核心——只要系统资源充足（如 8 个线程 + 8 核），即可天然实现并行；
❌ 单核系统或资源严重受限时，则退化为时间片轮转的并发调度（cooperative/preemptive），即“伪并行”。
⚠️ 关于“JDK 1.7 开始 core-aware”的说法存在常见误解。Java 并未在 1.7 引入新的线程调度机制，也未修改线程模型。所谓“core-aware”实为 HotSpot JVM 对 NUMA 架构优化、GC 线程亲和性（如 -XX:+UseNUMA）、以及 ForkJoinPool 默认并行度自动适配可用处理器数（Runtime.getRuntime().availableProcessors()）等特性的逐步增强。这些改进提升了并行效率，但不改变“并发是语义、并行是实现”的根本原则。
各线程执行框架的并发/并行特性对比
| 框架 | 并发保障 | 并行能力 | 关键说明 |
|---|---|---|---|
| Thread / Runnable | ✅ 语言级强保证（JMM） | ✅ 多核下自动并行（OS 调度） | 最基础抽象，无内置任务分发或负载均衡 |
| ExecutorService（如 ThreadPoolExecutor） | ✅ 继承 Thread 并发语义 | ✅ 可并行，取决于核心线程数 & CPU 核心数 | 若 corePoolSize = 4 且系统有 4+ 核，4 个线程可真正并行；若 corePoolSize = 1，则仅并发不并行 |
| ForkJoinPool | ✅ 完全兼容 JMM，并发安全 | ✅ 默认并行度 = availableProcessors()，支持工作窃取（work-stealing） | 专为递归分治任务优化，即使任务数 > 核心数，仍能高效利用所有核心： java ForkJoinPool pool = new ForkJoinPool(); // 默认使用全部可用核心 pool.invoke(new MyRecursiveTask()); |
实践建议与注意事项
-
✅ 不要硬编码线程数：优先使用 Runtime.getRuntime().availableProcessors() 动态配置线程池大小，避免在容器化环境（如 Docker 限制 CPU quota）中过度分配；
-
✅ 区分 I/O 密集型与 CPU 密集型任务：CPU 密集型推荐 corePoolSize ≈ availableProcessors()；I/O 密集型可适当放大（如 ×2），以掩盖阻塞开销；
-
❌ 勿依赖“JDK 版本决定并行”：并行能力由 OS + JVM + 硬件共同决定。测试时应使用 jstack 或 JFR（Java Flight Recorder）观察实际线程状态（RUNNABLE 状态线程若长期处于 on-CPU，即表明并行发生）；
