📚 喵喵的笔记库

深入理解高并发编程核心原理与案例实战

32分钟阅读

1. 全书概览

一本从操作系统底层讲起、一路打到分布式架构的 Java 并发编程实战书，不只是教你怎么用 synchronized，而是讲清楚"为什么会出 bug"。

全书 347 页，彩印，分四大板块 20 章，结构如下：

| 篇章 | 章节 | 主题 | 一句话概括 | |------|------|------|-----------| | 第1篇 | 第1~2章 | 基础知识 | 从 CPU 架构和操作系统线程调度讲起，建立并发编程的物理直觉 | | 第2篇 | 第3~14章 | 核心原理 | 12 章篇幅，用大量图解拆解原子性、可见性、有序性、synchronized、AQS、Lock、CAS、死锁、锁优化、线程池、ThreadLocal | | 第3篇 | 第15~18章 | 实战案例 | 手写线程池、CAS 自旋锁、读写锁缓存、AQS 可重入锁——四个完整项目级案例 | | 第4篇 | 第19~20章 | 系统架构 | 分布式锁架构 + 秒杀系统架构，站在架构师视角看并发 |

这本书在市面上同类书里的差异化优势：不只是源码分析，也不只是 API 手册，而是把"原理→实现→实战→架构"串成一条完整链路。案例代码有 GitHub 源码仓库（mykit-concurrent-principle），可以边看边跑。

2. 逐章要点

第1~2章：基础知识篇

这两章是全书的地基。冰河没有直接跳进 Java API 讲用法，而是先从冯·诺依曼体系结构、CPU 架构（寄存器、缓存、多核）讲起，解释了操作系统线程调度的机制——时间片轮转、优先级调度、上下文切换的开销。

核心观点：不理解硬件和操作系统层面的线程模型，就永远只能在"知道怎么用"的层面打转，遇到诡异 bug 会束手无策。

Java 线程和操作系统线程的关系（1:1 模型）也在这部分交代清楚——每个 Java Thread 背后都是一个内核线程，这也是为什么 Java 线程创建成本高的根本原因（后来虚拟线程 Loom 才试图改变这一点）。

并发编程的基本概念、三大风险（安全性问题、活跃性问题、性能问题）、锁的基本分类（乐观锁/悲观锁、独享锁/共享锁、公平锁/非公平锁）也在第 2 章集中铺开。

| 关键概念 | 说明 | |---------|------| | 上下文切换 | CPU 保存/恢复线程状态的过程，每次切换约几微秒，高频切换是性能杀手 | | 线程安全的三要素 | 原子性、可见性、有序性 | | 死锁 | 两个或以上线程互相等待对方持有的锁，全部阻塞 | | 活锁 | 线程不断重试但没有进展，像两个人在走廊里反复侧身让路 | | 饥饿 | 某个线程长时间得不到执行机会（被优先级更高的线程抢占） |

  • [ ] 复习冯·诺依曼体系结构，搞清楚 CPU 缓存（L1/L2/L3）和主存的层级关系
  • [ ] 用 jstack 查看一次自己项目中的线程状态，理解线程调度的实际情况
  • [ ] 手动写一个死锁程序并用 jstack 或 VisualVM 分析

第3~4章：并发编程的三大核心问题与本质

这两章是全书的理论核心。冰河提出了并发编程的三大核心问题：原子性问题、可见性问题、有序性问题。

  • 原子性问题：一个操作或多个操作要么全部执行且不被中断，要么全不执行。典型场景是 i++ 看起来是一步，实际上是读-改-写三步。
  • 可见性问题：一个线程修改了共享变量，其他线程不能立刻看到新值。根源在 CPU 缓存——每个核心有自己的 L1/L2 缓存，写回主存的时间不确定。
  • 有序性问题：编译器和 CPU 为了优化性能会重排序指令，单线程下没问题，多线程下可能出 bug。

核心观点：并发编程的所有诡异 bug，归根结底都可以归结到这三个问题上。搞清楚了这三个问题的根源，排查并发 bug 就不再是玄学。

Java 内存模型（JMM）在这两章被引入，作为解决这三个问题的规范框架。JMM 定义了线程和主存之间的抽象关系，规定了线程对共享变量的操作规则。

  • [ ] 写一段代码演示可见性问题（一个线程改 volatile 变量，另一个线程读），对比 volatile 和不用 volatile 的区别
  • [ ] 画出 CPU 缓存和主存的关系图，标注出可见性问题发生的环节
  • [ ] 复习 happens-before 原则的 8 条规则，每条用一个简单代码示例验证

第5~6章：原子性核心原理 & 可见性与有序性核心原理

第 5 章深入原子性的实现机制。synchronized 的底层通过 monitor 实现（monitorenter/monitorexit 指令），Lock 通过 AQS 实现，原子类通过 CAS + volatile 实现。三种路径，同一个目标：保证操作的原子性。

第 6 章是全书最硬核的章节之一。冰河用大量图解说明了：

  • volatile 关键字的语义：禁止指令重排序 + 保证可见性（通过内存屏障实现）
  • happens-before 原则：8 条规则定义了操作之间的可见性保证
  • as-if-serial 语义：单线程下重排序不影响执行结果

核心观点：volatile 只能保证可见性和有序性，不能保证原子性。volatile int i; i++ 依然不是线程安全的——这是面试高频坑。

| 关键概念 | 说明 | |---------|------| | 内存屏障 | CPU 提供的指令，阻止屏障前后的指令重排序，强制刷新缓存 | | happens-before | JMM 定义的可见性规则，如果 A happens-before B，则 A 的结果对 B 可见 | | as-if-serial | 编译器和处理器的优化原则：单线程程序的执行结果不能被改变 | | volatile 语义 | 可见性（每次读从主存读）+ 有序性（禁止重排序），但不保证原子性 |

  • [ ] 用 javap -c 反编译一段 synchronized 代码，找到 monitorenter/monitorexit 指令
  • [ ] 写代码验证 volatile 不能保证 i++ 的原子性
  • [ ] 整理 happens-before 8 条规则，用自己的话复述每条

第7章：synchronized 核心原理

synchronized 是 Java 并发编程的"老牌选手"，也是面试出场率最高的关键字之一。冰河从 JVM 层面完整拆解了它的实现：

  • 对象头中的 Mark Word 结构（存储锁状态、线程 ID、GC 年龄等信息）
  • 锁升级过程：无锁 → 偏向锁 → 轻量级锁 → 重量级锁
  • 偏向锁的撤销和批量重偏向
  • 轻量级锁的自旋策略
  • 重量级锁的 monitor 机制（ObjectMonitor 的 EntryList、WaitSet、Owner）

核心观点：JDK 6 之后的锁优化让 synchronized 的性能大幅提升，在大多数场景下已经和 ReentrantLock 不相上下，没必要一上来就用 ReentrantLock。

| 关键概念 | 说明 | |---------|------| | Mark Word | 对象头的一部分，32/64 位，存储哈希码、GC 年龄、锁标志位、线程 ID | | 偏向锁 | 第一个获取锁的线程记录在对象头，后续同线程进入不需要 CAS | | 轻量级锁 | 多线程竞争不激烈时，用 CAS 替代操作系统互斥量 | | 重量级锁 | 竞争激烈时，膨胀为操作系统级别的互斥锁，涉及用户态/内核态切换 | | 锁消除 | JIT 编译器优化，消除不可能被共享的锁（如 StringBuffer 的局部变量） |

  • [ ] 用 JOL 工具打印一个对象的对象头信息，观察锁状态变化
  • [ ] 写代码触发锁升级过程（从偏向锁到轻量级锁再到重量级锁），用 -XX:+PrintFlagsFinal 观察参数
  • [ ] 对比 synchronized 和 ReentrantLock 的性能差异，在高/低竞争两种场景下分别测试

第8~9章：AQS 核心原理 & Lock 锁核心原理

AQS（AbstractQueuedSynchronizer）是 JUC 包的灵魂，ReentrantLock、CountDownLatch、Semaphore、ReentrantReadWriteLock 都基于它实现。

AQS 的核心数据结构是一个 FIFO 的 CLH 双向队列 + volatile int state。冰河用图解的方式把独占模式和共享模式的获取/释放流程画得非常清楚：

  • 独占模式：tryAcquire → 失败则入队 → 自旋/park → 被唤醒后重新 tryAcquire
  • 共享模式：tryAcquireShared → 成功则传播唤醒后继节点

Lock 锁章节则在 AQS 基础上讲了 ReentrantLock、ReentrantReadWriteLock、StampedLock 的实现差异和适用场景。

核心观点：理解了 AQS，就理解了 JUC 并发包一半以上的工具类。AQS 是 Java 并发编程的"基础设施"。

| 关键概念 | 说明 | |---------|------| | CLH 队列 | AQS 内部的等待队列，每个节点记录前驱和后继，形成双向链表 | | state | AQS 的核心状态变量，volatile 修饰，子类通过 CAS 修改它来表达锁状态 | | 独占模式 | 同一时刻只有一个线程能获取同步状态（如 ReentrantLock） | | 共享模式 | 多个线程可同时获取同步状态（如 Semaphore、CountDownLatch） | | StampedLock | 读写锁的优化版，支持乐观读，性能比 ReentrantReadWriteLock 更好 |

  • [ ] 阅读 AQS 源码中的 acquire() 和 release() 方法，画出完整调用链
  • [ ] 基于 AQS 手写一个简单的互斥锁
  • [ ] 对比 ReentrantReadWriteLock 和 StampedLock 的性能差异

第10章：CAS 核心原理

CAS（Compare-And-Swap）是无锁编程的基石。冰河从 CPU 指令层面解释了 CAS 的实现（x86 的 CMPXCHG 指令），以及 Java 中 Unsafe 类对 CAS 的封装。

CAS 的三个问题也在本章详细讨论：

  1. ABA 问题：值从 A 改到 B 再改回 A，CAS 认为"没变过"。解决方案是用版本号（AtomicStampedReference）
  2. 自旋开销：长时间 CAS 失败会导致 CPU 空转。解决方案是限制自旋次数或用 LongAdder
  3. 只能保证单个共享变量的原子操作：多变量需要用 AtomicReference 或锁

核心观点：CAS 是乐观锁的底层实现，几乎所有无锁数据结构（ConcurrentHashMap、ConcurrentLinkedQueue）都依赖它。但 CAS 不是万能药，高竞争场景下自旋的 CPU 开销可能比锁还大。

  • [ ] 用 AtomicStampedReference 解决 ABA 问题，写一个可复现 ABA 的测试用例
  • [ ] 在高并发场景下对比 AtomicLong 和 LongAdder 的性能
  • [ ] 阅读 Unsafe 类的 compareAndSwapInt 源码，理解 JNI 调用

第11章：死锁核心原理

死锁的四个必要条件（互斥、持有并等待、不可抢占、循环等待）在这章被详细展开。冰河不仅讲了如何避免死锁，还提供了实用的诊断方法：

  • jstack 查看线程 dump 中的死锁信息
  • jconsole 和 VisualVM 的线程分析功能
  • 代码层面的预防策略：固定加锁顺序、tryLock 设置超时

| 死锁预防策略 | 说明 | |-------------|------| | 破坏互斥条件 | 基本不可能，锁的本质就是互斥 | | 破坏持有并等待 | 一次性获取所有需要的锁 | | 破坏不可抢占 | 使用 tryLock(timeout)，超时释放 | | 破坏循环等待 | 给锁编号，按固定顺序获取 |

  • [ ] 写一个必然产生死锁的程序，用 jstack 分析并确认
  • [ ] 用 tryLock + 超时改造上面的死锁程序，验证不再死锁
  • [ ] 在自己的项目中加入死锁检测的监控机制

第12章：锁优化

JVM 层面的锁优化技术在这一章集中讲解。这些优化大多在 JDK 6 之后引入，让 synchronized 从"性能差"变成了"大多数场景够用"：

  • 锁消除：JIT 通过逃逸分析，消除不会被共享的锁
  • 锁粗化：将多次连续的加锁/解锁合并为一次
  • 自旋锁与自适应自旋：轻量级锁失败后不自旋而是进入阻塞，或者根据历史成功率动态调整自旋次数
  • 偏向锁批量重偏向和批量撤销：当大量对象不再被偏向时，批量处理

核心观点：JVM 的锁优化是透明的，你不需要手动开启。但理解这些优化能帮你做出更好的架构决策——什么时候用 synchronized，什么时候用 Lock，什么时候用无锁方案。

  • [ ] 用 JITWatch 或 -XX:+PrintCompilation 观察锁消除的实际效果
  • [ ] 写一个循环中频繁加锁/解锁的案例，观察锁粗化前后的性能差异

第13章：线程池核心原理

线程池是 Java 并发编程中使用频率最高的组件，没有之一。冰河从源码层面完整剖析了 ThreadPoolExecutor：

  • 核心参数：corePoolSize、maximumPoolSize、keepAliveTime、workQueue、handler
  • 任务提交流程：核心线程满 → 队列满 → 非核心线程满 → 拒绝策略
  • Worker 的设计：Worker 继承 AQS 实现了不可重入特性，保证线程执行 task 时的状态安全
  • shutdown vs shutdownNow：优雅关闭 vs 强制关闭
  • 线程池大小的设置：CPU 密集型 = CPU 核数 + 1，IO 密集型 = CPU 核数 * 2 或更多

| 关键概念 | 说明 | |---------|------| | Worker | ThreadPoolExecutor 内部类，封装工作线程，继承 AQS | | 拒绝策略 | AbortPolicy（抛异常）、CallerRunsPolicy（调用者执行）、DiscardPolicy（丢弃）、DiscardOldestPolicy（丢弃最老） | | 优雅关闭 | 先调用 shutdown()，再 awaitTermination()，设置合理的超时时间 | | 线程复用 | Worker.runWorker() 中通过 getTask() 循环获取任务，实现线程复用 |

  • [ ] 画出 ThreadPoolExecutor.execute() 的完整流程图
  • [ ] 用不同拒绝策略测试线程池满载时的行为
  • [ ] 实现一个带监控指标的线程池包装类，记录提交任务数、完成数、拒绝数、队列长度

第14章：ThreadLocal 核心原理

ThreadLocal 提供了线程隔离的变量存储，每个线程有自己独立的副本。冰河从源码层面分析了：

  • ThreadLocalMap 的实现：每个 Thread 对象持有一个 ThreadLocalMap，key 是 ThreadLocal 的弱引用，value 是强引用
  • 内存泄漏的根源：ThreadLocal 对象被回收后，key 变成 null，但 value 不会被回收（强引用链：Thread → ThreadLocalMap → Entry → value）
  • InheritableThreadLocal：子线程自动继承父线程的 ThreadLocal 值

核心观点：ThreadLocal 的内存泄漏是面试高频题，但生产环境中的实际风险往往被夸大。只要在使用完后调用 remove()，问题基本不会出现。

  • [ ] 写代码复现 ThreadLocal 内存泄漏（用 WeakReference 和 ReferenceQueue 验证）
  • [ ] 在项目中用 ThreadLocal 实现数据库连接/事务上下文传递
  • [ ] 对比 ThreadLocal 和 InheritableThreadLocal 在线程池场景下的行为差异

第15~18章：实战案例篇

这是全书最有价值的部分之一。四个完整的实战案例，每个都是核心原理的落地实现：

第15章：手动开发线程池实战 不依赖 JDK 的 ThreadPoolExecutor，从零实现一个线程池。涉及任务队列、Worker 管理、拒绝策略、优雅关闭等完整功能。手写一遍之后，对 JDK 线程池的实现会有"原来如此"的感觉。

第16章：基于 CAS 实现自旋锁实战 用 CAS 实现一个自旋锁，并在此基础上实现可重入版本。核心思路：用 AtomicReference 记录当前持有锁的线程，compareAndSet(null, currentThread) 获取锁。

第17章：基于读写锁实现缓存实战 用 ReentrantReadWriteLock 实现一个本地缓存。读操作获取读锁（多线程可并发读），写操作获取写锁（独占）。这是读写锁最经典的应用场景。

第18章：基于 AQS 实现可重入锁实战 继承 AQS 实现 tryAcquire/tryRelease，手写一个可重入的互斥锁。这个案例直接对应了第 8 章的理论，是"理论→实践"的完美闭环。

核心观点：看懂源码和自己手写一遍是两个完全不同的层次。这四个案例的价值不在于生产中直接使用（直接用 JDK 的就好），而在于通过手写建立对底层原理的肌肉记忆。

| 实战案例 | 对应原理 | 核心收获 | |---------|---------|---------| | 手动开发线程池 | 第13章 线程池原理 | 理解 Worker、任务队列、拒绝策略的内部机制 | | CAS 自旋锁 | 第10章 CAS 原理 | 掌握无锁编程的基本模式 | | 读写锁缓存 | 第9章 Lock 锁原理 | 理解读写锁的典型应用场景 | | AQS 可重入锁 | 第8章 AQS 原理 | 理解 AQS 的独占模式工作流程 |

  • [ ] 跟着书手写四个实战案例，每写完一个用单元测试验证
  • [ ] 在手写线程池中加入线程池状态监控（活跃线程数、队列大小、完成任务数）
  • [ ] 在读写锁缓存中加入过期策略和容量限制

第19~20章：系统架构篇

最后两章把视角从"代码层面"拉到"架构层面"：

第19章：分布式锁架构 从单机锁到分布式锁的演进。冰河介绍了基于 Redis（SETNX + 过期时间）、基于 ZooKeeper（临时顺序节点）、基于 MySQL（唯一索引/for update）三种实现方式，以及各自的优势和坑。

  • Redis 分布式锁的续期问题（Redisson 的看门狗机制）
  • ZooKeeper 分布式锁的羊群效应和顺序节点优化
  • 分布式锁的超时、重试、容错设计

第20章：秒杀系统架构 秒杀是高并发编程的"终极考题"。冰河从前端限流、网关层、服务层、数据库层逐层分析：

  • 前端：按钮防抖、验证码、静态化
  • 网关：令牌桶限流、IP 黑名单
  • 服务层：本地缓存 + Redis 缓存 + 异步下单（消息队列削峰）
  • 数据库：乐观锁（版本号）、库存扣减用行锁而非表锁

核心观点：真正的秒杀系统不是靠某个并发技巧解决的，而是靠多层防御架构——从 CDN 到网关到服务到数据库，每一层都在"挡"流量。高并发架构的本质是"分层限流 + 异步削峰 + 缓存为王"。

  • [ ] 用 Redis 实现一个简单的分布式锁，考虑续期和可重入
  • [ ] 画出完整的秒杀系统架构图，标注每一层的限流策略
  • [ ] 用 JMeter 或 wrk 压测一个简单的接口，观察从低并发到高并发的性能变化

3. 关键概念速查

| 概念 | 定义 | 一句话理解 | |------|------|-----------| | JMM (Java Memory Model) | Java 虚拟机规范中定义的一套规则，规定线程如何与主存交互 | Java 并发编程的"交通规则"，告诉编译器和 CPU 什么能优化、什么不能 | | CAS (Compare-And-Swap) | CPU 提供的原子指令，比较内存值是否等于预期值，等于则更新 | "先看一眼再改，改的时候别人不能插手" | | AQS (AbstractQueuedSynchronizer) | JUC 包中同步器的抽象基类，用 state + CLH 队列管理同步状态 | Java 并发包的"总后台"，ReentrantLock、Semaphore 等都找它办事 | | volatile | Java 关键字，保证共享变量的可见性和有序性（不保证原子性） | "我改了，你们都看着"——但两个人同时改还是会打架 | | 锁升级 (Lock Escalation) | JDK 6+ 的优化，synchronized 锁从偏向锁 → 轻量级锁 → 重量级锁逐步升级 | 先试便宜的办法，不行再用贵的 | | happens-before | JMM 定义的 8 条可见性规则，定义操作之间的先后关系 | "如果 A 在 B 前面发生，那 B 一定能看到 A 的结果" | | CLH 队列 | AQS 内部使用的 FIFO 等待队列，每个节点记录前后节点 | "排队等锁的队伍，前面的人办完了叫下一个" | | ThreadLocal | 线程局部变量，每个线程有自己的独立副本 | "各干各的，互不干扰"——但用完要记得清理 |

4. 核心框架/模型

并发编程问题排查框架

遇到并发 bug 时，按这个思路排查：

Step 1: 是什么问题？
┌─────────────┬──────────────────┬──────────────────┐
│   原子性问题  │    可见性问题     │    有序性问题     │
│ (操作被打断)  │ (改了别人看不到)   │ (指令被偷偷换序)   │
└──────┬──────┴────────┬─────────┴────────┬─────────┘
       │               │                  │
       ▼               ▼                  ▼
   加锁/CAS        volatile           volatile/final
   Atomic类        synchronized       happens-before

synchronized 锁升级过程

                    ┌─────────────┐
                    │   无锁状态    │
                    └──────┬──────┘
                           │ 第一个线程获取锁
                           ▼
                    ┌─────────────┐
                    │   偏向锁     │ ← 同一线程再次进入无开销
                    └──────┬──────┘
                           │ 第二个线程竞争
                           ▼
                    ┌─────────────┐
                    │  轻量级锁    │ ← CAS 自旋尝试获取
                    └──────┬──────┘
                           │ 自旋失败（竞争激烈）
                           ▼
                    ┌─────────────┐
                    │  重量级锁    │ ← 操作系统互斥量，涉及用户态/内核态切换
                    └─────────────┘

AQS 工作流程（独占模式）

线程调用 acquire()
        │
        ▼
  tryAcquire(state) ──成功──→ 获取锁，执行业务逻辑
        │
     失败 │
        ▼
  addWaiter() 入队（CLH 队列尾部）
        │
        ▼
  acquireQueued() 自旋/Park
        │
     被前驱节点 unpark() 唤醒
        │
        ▼
  再次 tryAcquire(state) ──成功──→ 设置 head，返回

高并发架构分层防御模型

用户请求 → CDN/静态化 → WAF → 网关限流 → 服务限流 → 本地缓存 → Redis → MQ 削峰 → DB
              ↓           ↓       ↓          ↓          ↓          ↓        ↓       ↓
            挡 80%      挡恶意    令牌桶/漏桶   Sentinel   Caffeine   热点缓存   Kafka   乐观锁
            静态请求     请求      控制入口速率   信号量      读多写少    读多写少   异步落库  库存扣减

5. 金句摘录

并发编程并不像其他业务那样简单明了。在编写并发程序时，往往会出现各种诡异的 Bug 问题，这种 Bug 问题会常常以某种诡异的现象出现，这种现象又会迅速消失，并且这种问题在大部分场景下又很难复现。

纵观整个图书市场，几乎找不到一本全面并且细致地介绍有关高并发编程的基础知识、核心原理、实战案例和系统架构的图书。

JDK 中这些并发编程的类库经历了实际生产环境中高并发、大流量的考验，是学习高并发编程非常好的实践案例。

看懂源码和自己手写一遍是两个完全不同的层次。

高并发架构的本质是"分层限流 + 异步削峰 + 缓存为王"——从 CDN 到网关到服务到数据库，每一层都在"挡"流量。

6. 行动清单

每天

  • [ ] 写一段并发代码练手（10 分钟）：可以是 CAS 操作、线程池配置、锁的使用等小片段
  • [ ] 复习一个并发面试题（15 分钟）：用自己的话讲给别人听，讲不清楚就是没理解

每周

  • [ ] 阅读一个 JUC 源码类的核心方法（如 ReentrantLock.lock()、ConcurrentHashMap.put()），用注释标注理解
  • [ ] 在自己的项目中找一个可以用并发优化的点，尝试改进并做性能对比测试

每月

  • [ ] 完成书中一个实战案例（手写线程池 / CAS 自旋锁 / 读写锁缓存 / AQS 可重入锁），从零写到能跑
  • [ ] 用压测工具（JMeter / wrk / k6）对自己服务的某个接口做并发压测，找出瓶颈并优化
  • [ ] 输出一篇并发编程相关的技术文章或笔记，教别人是最好的学习方式

7. 一句话总结

搞并发不是背 API，而是从 CPU 缓存到操作系统线程，从 Java 内存模型到 AQS 源码，从单机锁到分布式架构，一层一层往下挖，直到你看到问题的根。

8. 读者热议

"冰河的公众号连载我追了很久，这本书把散落的文章系统化了，图解很清晰，适合反复翻" 认同度：⭐⭐⭐⭐⭐ — 这本书确实是从冰河公众号的【精通高并发系列】专栏演化而来，经过系统重构后结构比零散文章好很多。大量图解是这本书的一大卖点。

"实战案例篇最有价值，手写线程池那段让我对 ThreadPoolExecutor 的理解上了一个台阶" 认同度：⭐⭐⭐⭐⭐ — 完全同意。看源码是"看别人怎么做"，手写是"自己做一遍"，认知差距是巨大的。四个实战案例对应了四个核心原理，选得很有针对性。

"基础篇从 CPU 架构讲起很好，但部分内容对有经验的开发者来说偏水，可以快速跳过" 认同度：⭐⭐⭐⭐ — 确实，如果你已经知道冯·诺依曼体系和操作系统线程模型，前两章可以快速过。但如果你之前只写过 CRUD 从来没想过"线程在硬件上到底怎么跑"，这部分反而是最有价值的。

"JDK 核心技术那本是这本的补充，两本一起看效果最好，单独看这本对 JDK 并发工具类的覆盖还不够" 认同度：⭐⭐⭐⭐ — 这本书的核心是"原理"，JDK 并发工具类（ConcurrentHashMap、ConcurrentLinkedQueue 等）的详细源码分析确实在后续的《JDK 核心技术》中。如果只想买一本，这本更适合打基础；想深入学习 JDK 实现的，两本都看。

"秒杀系统那章偏简略，更适合入门了解，离真正的生产级秒杀还有距离" 认同度：⭐⭐⭐ — 同意。347 页的书里只用了一章讲秒杀架构，确实只能点到为止。但作为"站在架构层面理解高并发编程"的入门引子，方向是对的，具体的落地细节需要配合其他资料。

笔记生成：2026-04-28 by 喵喵 🐈

相关笔记

同作者仅有此篇 同主题：

关系图谱