java并发编程核心在于理解内存模型、状态共享与协作机制，需掌握volatile、synchronized原理、jdk并发工具类边界、线程池调优及竞态排查方法。
Java 并发编程不是“学完 Thread 就能写并发”的事，核心在于理解内存模型、状态共享与协作机制。没吃透 volatile 和 happens-before 规则，写出来的 synchronized 代码可能看似安全，实则存在重排序或可见性漏洞。
从线程生命周期到正确共享变量
很多初学者卡在“为什么加了 synchronized 还有脏读”——问题常出在锁对象不一致、锁粒度错配，或误以为锁能保证所有字段的可见性。实际中，synchronized 只保障临界区互斥 + 锁释放时刷新主存，但若字段本身未被锁保护（比如在同步块外读写），仍可能看到过期值。
-
Thread.start()启动的是新线程，run()直接调用只是普通方法执行，不并发 -
volatile解决单变量可见性+禁止指令重排，但不保证复合操作原子性（如i++） - 静态变量被多个线程访问时，必须明确其初始化时机：类加载时初始化是线程安全的；运行时懒初始化需用
double-checked locking或static inner class
必须掌握的 JDK 并发工具类使用边界
别把 ConcurrentHashMap 当万能容器。它只保证单个操作（put、get）线程安全，ifAbsentPut 类逻辑仍需额外同步；CopyOnWriteArrayList 适合读多写少且迭代期间不能抛 ConcurrentModificationException 的场景，但写操作会复制整个数组，大数据量下 GC 压力明显。
-
AtomicInteger底层依赖Unsafe.compareAndSwapInt，失败时自旋重试，高竞争下 CPU 消耗大 -
ReentrantLock支持可中断等待（lockInterruptibly()）、超时获取（tryLock(long, TimeUnit)）、公平锁配置，但必须手动unlock()，建议用try-finally包裹 -
CountDownLatch是一次性门闩，CyclicBarrier可重复使用，但后者内部用ReentrantLock实现，重置时有短暂阻塞窗口
线程池不是越大越好：参数组合的真实影响
Executors.newFixedThreadPool(10) 看似稳妥，但任务队列用的是无界 LinkedBlockingQueue，一旦任务提交速度持续超过处理速度，内存会不断增长直至 OutOfMemoryError。生产环境必须显式构造 ThreadPoolExecutor，并根据任务类型选择队列策略。
立即学习“Java免费学习笔记（深入）”；
- CPU 密集型任务：线程数 ≈
Runtime.getRuntime().availableProcessors()，避免频繁上下文切换 - IO 密集型任务：线程数可设为
2 × availableProcessors()或更高，但需配合短超时和连接池控制总资源占用 - 拒绝策略选
AbortPolicy（抛RejectedExecutionException）比CallerRunsPolicy更利于快速暴露容量瓶颈
排查并发问题的关键路径
线上出现偶发超时或数据不一致，别急着改代码。先确认是否复现稳定 —— 若只能“有时发生”，大概率是竞态条件；用 jstack -l <pid></pid> 查看线程堆栈和锁持有关系，重点关注 WAITING、BLOCKED 状态及锁 ID；对可疑对象做堆转储（jmap -dump:format=b,file=heap.hprof <pid></pid>），用 JVisualVM 或 Eclipse MAT 分析对象引用链和锁竞争热点。
-
ThreadLocal不是线程安全银弹：若在线程池中使用未清理，会造成内存泄漏（key 为弱引用，value 强引用残留） - 日志中打印线程名（
Thread.currentThread().getName()）比打固定字符串更能定位执行上下文 - JDK9+ 的
Thread::getStackTrace()开销显著降低，可在低频监控点安全使用
真正难的不是记住 API，而是判断某段逻辑里哪些状态需要保护、用什么粒度保护、以及保护之后是否引入了新的死锁或性能拐点。比如一个缓存更新操作，既要防止重复加载，又要避免旧值长期滞留，还要兼容失效通知——这时候往往得组合 ConcurrentHashMap.computeIfAbsent、StampedLock 和 CompletableFuture，而不是套用单一工具。
