并发编程核心难点在于可见性、原子性、重排序、竞态条件、中断响应与死锁的综合处理：volatile解决可见性但不保原子性，synchronized和Lock兼顾二者却有开销，CAS类操作需谨慎使用，组合操作须额外同步，中断依赖线程主动响应，死锁源于锁序不一致，而“何时加锁、加多大”才是最易出错的边界问题。
共享变量的可见性没保障
多个线程读写同一个 int count 或 boolean flag 时，一个线程改了值，另一个线程可能永远看不到——这不是代码写错了，而是 JVM 可能把变量缓存在 CPU 寄存器或本地 L1 缓存里，不主动刷回主内存。
- 用
volatile能强制读写都走主内存，但不能保证复合操作（比如i++）原子性 -
synchronized块或ReentrantLock能同时解决可见性和原子性，但会带来阻塞开销 - JIT 编译器还可能重排序指令，
volatile和锁能插入内存屏障禁止这种重排
竞态条件（Race Condition）藏得深
看似安全的逻辑，只要没加锁或没用原子类，就可能在高并发下崩。比如 if (list.isEmpty()) list.add(x)，两个线程同时通过判空，结果插入重复元素；又比如 ConcurrentHashMap 的 computeIfAbsent 在某些 JDK 版本里对 null 返回值处理不一致，导致重复计算。
- 判断 + 操作（check-then-act）必须整体原子化，不能靠“应该不会同时发生”来赌
- 用
AtomicInteger.compareAndSet()、ConcurrentHashMap.compute()等内置原子语义代替手写逻辑 - 哪怕用了线程安全集合，组合操作（如先取再删）仍需额外同步
线程生命周期和状态难掌控
Thread.stop() 已废弃，Thread.interrupt() 只是设个标志位，真正响应与否全看线程自己是否检查 isInterrupted() 或是否在可中断的阻塞点（如 Object.wait()、Thread.sleep()、BlockingQueue.take()）上。
- 被
synchronized卡住的线程无法被中断，只能等锁释放 -
ExecutorService.shutdownNow()并不保证任务立即停止，只是发中断信号 + 清理队列 - 忘记在
finally块里恢复中断状态（Thread.currentThread().interrupt()），会导致上层调用者收不到中断
死锁不是只出现在教科书里
两个线程各自持有一个锁，又去申请对方持有的锁，就会卡死。更隐蔽的是锁顺序不一致：模块 A 先锁 lockA 再锁 lockB，模块 B 反过来，只要并发时机凑巧，就触发死锁。
立即学习“Java免费学习笔记（深入）”；
- JDK 自带
jstack能 dump 出死锁线索，但生产环境往往要等很久才复现 - 用
tryLock(timeout, TimeUnit)可避免无限等待，但得处理超时后的回滚逻辑 - 锁粒度越小越好，但别为了“无锁”强行用
AtomicReference.updateAndGet()做复杂对象更新——CAS 失败重试成本可能更高
真正棘手的从来不是“怎么加锁”，而是“哪里该加”“加多大范围”“加了之后要不要响应中断”“加了之后别人会不会绕过它”。这些边界模糊的地方，才是并发 bug 最爱藏身的位置。
