并发是同一时间段内推进多个任务，多线程只是其实现手段之一；单线程通过异步非阻塞（如completablefuture、netty）也能实现并发，而多线程在单核cpu上仍是并发而非并行。
多线程是并发的一种实现方式，不是等价概念——并发是目标（同时处理多个任务），多线程是手段（用多个线程去达成它）。
并发 ≠ 多线程：单线程也能实现并发
很多人一提“并发”就默认要开一堆 Thread，其实完全没必要。比如：
- I/O 密集型场景下，用
CompletableFuture链式组合异步任务，主线程不阻塞，任务在回调中完成——这是并发，但没手动创建任何线程； - Netty 或 Spring WebFlux 的事件循环模型，靠单线程+非阻塞 I/O 处理成千上万连接，也是并发，甚至刻意避免多线程；
-
ExecutorService提交 10 个任务，背后只用 4 个线程轮着跑，任务数 > 线程数，照样算并发。
关键看是否“同一时间段内推进多个任务”，而不是是否开了多个线程。
多线程 ≠ 并行：单核 CPU 上永远是并发调度
你在四核机器上调 new Thread().start() 开了 8 个线程，不代表它们真正在“同时执行”。操作系统会按时间片轮转调度，每个线程只占几毫秒 CPU，然后切走——这叫并发。
立即学习“Java免费学习笔记（深入）”；
只有当线程数 ≤ 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模式，省心又安全。
这些细节不解决，再多线程也白搭：程序逻辑看似对，运行起来却间歇性错乱。
