Java多线程与并发编程区别详解

并发是同一时间段内推进多个任务，多线程只是其实现手段之一；单线程通过异步非阻塞（如CompletableFuture、Netty）也能实现并发，而多线程在单核CPU上仍是并发而非并行。

多线程是并发的一种实现方式，不是等价概念——并发是目标（同时处理多个任务），多线程是手段（用多个线程去达成它）。

并发 ≠ 多线程：单线程也能实现并发

很多人一提“并发”就默认要开一堆 Thread，其实完全没必要。比如：

• I/O 密集型场景下，用 CompletableFuture 链式组合异步任务，主线程不阻塞，任务在回调中完成——这是并发，但没手动创建任何线程；
• Netty 或 Spring WebFlux 的事件循环模型，靠单线程+非阻塞 I/O 处理成千上万连接，也是并发，甚至刻意避免多线程；
• ExecutorService 提交 10 个任务，背后只用 4 个线程轮着跑，任务数 > 线程数，照样算并发。

关键看是否“同一时间段内推进多个任务”，而不是是否开了多个线程。

多线程 ≠ 并行：单核 CPU 上永远是并发调度

你在四核机器上调 new Thread().start() 开了 8 个线程，不代表它们真正在“同时执行”。操作系统会按时间片轮转调度，每个线程只占几毫秒 CPU，然后切走——这叫并发。

只有当线程数 ≤ CPU 核心数，且没有 I/O 阻塞、锁竞争等干扰时，才可能达到物理并行。实操中常见误区：

• 盲目设置线程池大小为 Runtime.getRuntime().availableProcessors() * 10，结果上下文切换开销暴涨，吞吐反而下降；
• 在 synchronized 块里做 HTTP 调用或文件读写，线程卡在 I/O，其他线程干等，CPU 利用率低还假死；
• 用 volatile 修饰计数器想替代 AtomicInteger，结果 count++ 这种非原子操作仍导致数据丢失。

什么时候必须用多线程？看资源瓶颈类型

判断依据不是“我想并发”，而是“当前瓶颈在哪”：

• CPU 密集型（如图像压缩、加密解密、批量计算）→ 适合多线程 + 固定大小线程池（通常设为 availableProcessors()）；
• I/O 密集型（如数据库查询、HTTP 请求、日志落盘）→ 更适合异步非阻塞（CompletableFuture / WebClient），或配大一点的线程池（如 availableProcessors() * 2 ~ 4）；
• 混合型（如电商下单：查库存 → 扣减 → 发消息 → 写日志）→ 拆分阶段，I/O 部分异步化，CPU 部分用并行流或小线程池。

别忘了：Java 的 java.util.concurrent 包里大部分工具（ConcurrentHashMap、CountDownLatch、Phaser）设计初衷就是让多线程协作更安全，而不是鼓励你无脑加线程。

最容易被忽略的并发陷阱：可见性 + 重排序

写个 boolean running = true，另一个线程改了它，主线程却一直看不到更新？这不是 bug，是 JVM 允许的优化行为。

根本原因不在“多线程”，而在“内存模型”——每个线程有自己工作内存，变量修改不一定立刻刷回主存。解决方案很具体：

• 用 volatile 保证可见性和禁止指令重排序（适用于状态标志、简单布尔开关）；
• 用 final 字段确保构造安全（对象发布后字段不可变）；
• 用 synchronized 或 ReentrantLock 建立 happens-before 关系（不仅互斥，也强制刷新缓存）；
• 别自己写双检锁单例，直接用 Enum 或 Holder 模式，省心又安全。

这些细节不解决，再多线程也白搭：程序逻辑看似对，运行起来却间歇性错乱。