ide需手动配置jdk的src.zip才能查看concurrenthashmap等juc类的原始源码；forkjoinpool.commonpool()因共享性与阻塞风险应避免业务中直接调用；aqs的state字段由不同子类按需解读，需结合具体实现理解；phaser和stampedlock调试困难是因其大量使用unsafe导致ide断点失效。
在IDE里直接跳转ConcurrentHashMap等JUC类的源码
IntelliJ IDEA 或 Eclipse 默认不会把 rt.jar 里的 JUC 源码（即 java.util.concurrent）关联进来，所以点进去看到的是反编译结果，不是原始注释和实现逻辑。必须手动配置 JDK 源码路径。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 确认你用的 JDK 是完整版（非 JRE），且包含
src.zip（常见于 JDK 安装目录根路径下） - 在 IDEA 中：File → Project Structure → SDKs → 选中你的 JDK → Sourcepath → 点 + 号 → 添加
src.zip（不要解压） - 重启项目后，按住 Ctrl（或 Cmd）点击
AtomicInteger、ReentrantLock等类，就能看到带完整注释的源码 - 注意：某些 OpenJDK 构建版本（如 Amazon Corretto、Zulu）可能把源码放在
lib/src.zip或单独提供src目录，路径需对应调整
为什么ForkJoinPool的commonPool()不能随便调用
很多教程一上来就用 ForkJoinPool.commonPool().submit(...)，但这个线程池是全局共享的，且默认并行度 = CPU 核心数 − 1。一旦某个任务长时间阻塞（比如 IO），会拖垮所有依赖 common pool 的地方（包括 CompletableFuture 的默认异步方法）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 避免在业务代码中显式调用
commonPool()，尤其不能提交阻塞型任务（如Thread.sleep()、数据库查询） - 需要自定义并行行为时，用
new ForkJoinPool(parallelism)构造专属池子 - 查看
ForkJoinPool源码时重点看externalPush()和helpStealer()—— 这两个方法体现了工作窃取的核心逻辑，但注释极少，得结合 Doug Lea 的论文理解 - OpenJDK 17+ 中
commonPool已被标记为@Deprecated(forRemoval = true)，未来可能移除
AbstractQueuedSynchronizer（AQS）的state字段到底怎么用
AQS 是 ReentrantLock、Semaphore、CountDownLatch 的底层基石，但它的 state 是一个 int 类型的“万能状态位”，不同子类对它的解读完全不同 —— 这正是初读源码时最容易混淆的点。
实操建议：
立即学习“Java免费学习笔记（深入）”；
-
ReentrantLock把state当作重入次数（0=未锁，1=已锁，2=重入一次…） -
Semaphore把state当作剩余许可数（acquire() 减，release() 加） -
CountDownLatch把state当作倒计时初始值，只减不加，减到 0 后所有 await() 返回 - 阅读 AQS 源码时，不要从
acquire()入口硬啃，先定位到具体子类的tryAcquire(int)/tryRelease(int)实现，再回溯 AQS 如何调度它们 -
state是 volatile 修饰的，但 AQS 所有状态变更都通过Unsafe.compareAndSetInt()完成，不是简单的state++
调试Phaser或StampedLock时看不到线程挂起位置？
Phaser 和 StampedLock 大量使用 Unsafe.park() 和自旋逻辑，IDE 断点常停在 Unsafe 底层或 LockSupport，看不出业务上下文。这不是你配置错了，而是这些类有意规避 JVM 线程栈的常规可见性。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 别在
arriveAndAwaitAdvance()或writeLock()上直接打断点；改用日志 +phaser.getPhase()/stampLock.getReadLockCount()辅助判断状态 - 想观察线程阻塞链路，用
jstack -l <pid></pid>查看java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()类似堆栈，比 IDE 更真实 -
StampedLock的乐观读模式（tryOptimisticRead()）根本不进锁队列，源码里几乎全是Unsafe原子操作，调试意义有限，重点应放在「何时降级为悲观读」的条件判断上 - JDK 9+ 的
VarHandle正逐步替代Unsafe，但当前 JUC 主干仍以Unsafe为主，阅读时需习惯这种“绕过 Java 内存模型”的写法
真正卡住人的从来不是语法，而是 JUC 源码里那些没写进注释的隐含契约：比如 AQS 要求子类的 tryAcquire 必须是原子语义，比如 ConcurrentHashMap 的扩容触发不是看 size，而是看 bin 数和 threshold 的组合。这些细节只藏在代码分支和单元测试里。
