掌握Java多线程与高并发需理解四大本质：1.JMM解释可见性/有序性问题；2.锁升级机制说明synchronized性能优化；3.CAS原子类的自旋代价与适用场景；4.线程池参数反映资源博弈逻辑。
掌握 Java 多线程与高并发底层原理，关键不是死记 API，而是理解“为什么这样设计”——从内存怎么被多个线程看到，到锁怎么一步步变重，再到线程池怎么平衡资源与吞吐。下面四条主线，直击本质，帮你系统打通。
搞懂 JMM（Java 内存模型）：所有可见性、有序性问题的源头
JMM 不是物理内存结构，而是一套规则，定义线程如何读写共享变量。它强制两点：
- 每个线程都有自己的工作内存，所有读写操作先在工作内存中进行；
- 线程间不共享工作内存，变量值传递必须经由主内存中转。
这就解释了为什么没加同步时，一个线程改了变量，另一个线程看不到——因为修改还卡在它的本地缓存里。volatile 的作用，就是用内存屏障强制刷新和重载；synchronized 和 Lock 则靠“进入/退出临界区时清空/刷新工作内存”来保障可见性与有序性。
吃透锁升级机制：synchronized 不再是“重量级”的代名词
JVM 对 synchronized 做了深度优化，锁状态会随竞争程度动态升级：
立即学习“Java免费学习笔记（深入）”；
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 无锁 → 偏向锁（单线程访问，只记录线程 ID，几乎零开销）；
- 轻量级锁（多线程交替执行，用 CAS 尝试获取锁对象头）；
- 重量级锁（真正阻塞挂起，依赖操作系统 Mutex）。
理解这个过程，你就明白：低并发下 synchronized 性能很好；高竞争时它才退化为传统互斥锁。这也是为什么 JDK 1.6 之后，synchronized 反而比 ReentrantLock 在多数场景更轻量。
看穿 CAS 与原子类：无锁编程的真实代价
AtomicInteger 等原子类不是“真原子”，而是基于 CPU 的 CAS 指令实现的自旋重试：
- 读取当前值 → 比较是否仍为该值 → 是则更新，否则重试；
- volatile 保证每次读都是最新值，但 i++ 这种复合操作仍需循环 CAS；
- 高竞争下自旋会浪费 CPU，甚至引发 ABA 问题（可用 AtomicStampedReference 解决）。
所以原子类适合低到中等竞争场景；超高并发且逻辑复杂时，锁或更高级结构（如 LongAdder）反而更稳。
理清线程池参数背后的资源博弈逻辑
ThreadPoolExecutor 不是配置数字游戏，每个参数都对应真实资源约束：
- corePoolSize：长期驻留线程数，应匹配系统稳定负载（CPU 密集型 ≈ CPU 核数 + 1，IO 密集型可翻倍）；
- workQueue：不是越大越好，无界队列（如 LinkedBlockingQueue 默认无界）可能掩盖背压，导致 OOM；
- maximumPoolSize + 拒绝策略：是系统熔断开关，CallerRunsPolicy 让调用线程自己执行任务，是天然降级手段。
真正合理的线程池，是根据监控指标（如队列积压、拒绝率、平均响应时间）反推调整，而不是凭经验拍脑袋。
