Java并发编程中的坑

synchronized锁对象而非代码：锁静态方法锁的是Class对象，锁实例方法锁的是this对象。不同实例的同步方法互不影响。

volatile只保证可见性不保证原子性：i++这类复合操作仍需配合synchronized或Atomic类。DCL单例模式必须加volatile禁止指令重排。

线程池参数理解误区：corePoolSize核心线程可回收，allowCoreThreadTimeOut控制。workQueue满了才创建非核心线程，不是先创建线程再入队。

Future.get()的阻塞陷阱：默认无限等待，务必设置超时时间或使用CompletableFuture的回调机制。线程池提交任务后必须考虑结果处理。

ThreadLocal内存泄漏真相：Entry使用弱引用仅针对key，value仍为强引用。必须调用remove()清理，尤其在Web应用中。

锁升级不可逆过程：无锁→偏向锁→轻量级锁→重量级锁。偏向锁在竞争激烈时反而降低性能，可JVM参数关闭。

CAS的ABA问题解决方案：AtomicStampedReference加版本号，AtomicMarkableReference加标记位。并发修改需考虑状态连续性。

ConcurrentHashMap.size()不精确：弱一致性设计，统计时允许并发修改。需要精确计数时用LongAdder或单独维护。

线程中断机制：interrupt()只是设置标志位，线程需自行检查并处理。sleep()/wait()会清除中断状态并抛异常。

原子类不是万能：AtomicInteger适合计数器，AtomicReference适合对象替换。复杂状态更新仍需锁或compareAndSet循环。

死锁检测与避免：jstack查看线程状态，JDK自带jconsole可视化监测。编码时固定锁获取顺序可预防死锁。

CompletableFuture回调地狱：链式调用替代嵌套，exceptionally处理异常，thenCombine合并多个结果。异步编程需理清依赖关系。