java并发编程高级进阶重在理解jmm、合理选型同步机制、定制线程池、强化诊断能力，并严格保障共享可变状态的同步契约。
Java 并发编程的高级进阶，核心不在堆砌 API，而在于理解模型、识别陷阱、建立调试与设计直觉。重点是把“能跑”变成“可靠、可维护、可诊断”。
吃透 JMM（Java 内存模型）的真实含义
JMM 不是规范内存布局，而是定义线程间共享变量的可见性、有序性约束。很多并发 bug 源于误以为“写完就立刻对其他线程可见”或“代码顺序 = 执行顺序”。
- volatile 关键字本质是插入内存屏障（Memory Barrier），禁止重排序 + 强制刷新/读取主内存，但不保证复合操作原子性（如 i++）
- final 字段的初始化安全有特殊语义：构造器内对 final 字段的写入，对后续通过该引用读取它的线程保证可见 —— 这是安全发布对象的基础
- 用 happens-before 规则判断操作是否具备可见性保障（如锁释放 happens-before 锁获取、start() happens-before 线程内第一条语句）
超越 synchronized 和 ReentrantLock：合理选择同步机制
不同场景需要不同粒度和语义的同步工具，盲目统一用锁会掩盖问题或拖慢性能。
- 读多写少 → StampedLock（支持乐观读，无锁读路径快；注意其不支持重入、使用后需校验戳）
- 状态简单且无复杂依赖 → AtomicXXX 类（如 AtomicReferenceFieldUpdater 用于更新对象字段，避免为单个字段加锁）
- 需要条件等待且不想阻塞整个锁 → Condition 配合 ReentrantLock（一个锁可绑定多个 Condition，实现精准唤醒）
- 避免锁升级失败导致死锁 → 使用 tryLock(timeout) 主动超时，配合回退逻辑（如重试、降级）
线程池不是万能胶水：按业务特征定制与防护
Executors 工具类创建的线程池隐藏了关键参数，易引发 OOM 或响应延迟。高级用法必须直面参数含义与风险。
- 拒绝策略不能只用 AbortPolicy：根据场景选 DiscardPolicy（丢弃）、DiscardOldestPolicy（丢最老）、CallerRunsPolicy（由提交线程执行任务，自然限流）
- 核心线程数 ≠ CPU 核心数：IO 密集型任务可设为 2×CPU；计算密集型建议略大于 CPU 数（如 CPU+1），并配合监控调整
- 务必设置 ThreadFactory：命名线程便于排查（如 “order-processor-pool-%d”），并可统一设置守护状态、优先级、异常处理器
- 线程池应作为 Bean 管理生命周期：应用关闭前调用 shutdown() + awaitTermination()，防止任务丢失或进程无法退出
诊断比编码更关键：掌握真实线程行为
并发问题往往偶发、难复现。不靠日志和工具盲猜，要能定位到具体线程状态、锁竞争、内存泄漏点。
- 用 jstack
快速抓取线程快照，重点关注 WAITING / BLOCKED 状态及锁持有者（注意区分 jdk8 vs jdk11+ 的线程 dump 格式差异） - 用 jcmd
VM.native_memory summary 查看 JVM 原生内存占用，排查 DirectByteBuffer 泄漏或线程栈膨胀 - 在关键临界区加入 Thread.currentThread().getStackTrace() 日志（仅调试期启用），确认执行路径是否符合预期
- 借助 JMC（Java Mission Control） 开启飞行记录（Flight Recording），分析锁争用热点、GC 暂停、线程生命周期等长时间维度行为
不复杂但容易忽略：所有共享可变状态都必须有明确的同步契约——要么用线程安全类型封装，要么加锁，要么确保不可变。没有“差不多线程安全”的中间状态。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
