Java on Liangweidong's blog

AQS原理简述

Tue, 06 Mar 2018 00:00:00 +0000

§2.2.5 AQS原理简述

考察意图：理解AQS作为JUC基石的原理深度，而非泛泛而谈"抽象队列同步器"。

回答样板：

AQS（AbstractQueuedSynchronizer）是JUC锁和同步器（ReentrantLock、CountDownLatch、Semaphore等）的基石。

核心三要素：

volatile int state——同步状态（独占模式0表示未锁，大于0表示已锁；共享模式表示剩余资源数）
CLH变体双向队列——等待获取锁的线程队列，每个节点通过CAS和前驱节点的waitStatus状态协作
模板方法模式——子类实现tryAcquire/tryRelease等抽象方法决定同步语义，AQS内部维护队列和状态流转

独占模式获取锁流程：tryAcquire尝试获取 → 成功则返回 → 失败则将当前线程包装成Node加入等待队列 → 在队列中自旋或阻塞等待前驱节点唤醒。

项目层面：日常使用多是读API层面（直接用ReentrantLock、CountDownLatch），没有深入到定制AQS同步器那个层面。但对AQS的CLH队列原理、state状态机有清晰理解。

陷阱提示：说"精通AQS"结果说不出CLH队列原理；泛泛而谈"抽象队列同步器"没深度。

备选话术：我日常使用线程池处理异步任务（如设备数据批量写入），对JUC核心类有实操经验。但AQS源码实现细节或无锁编程（CAS/Unsafe）不是日常写代码的层面，坦诚需要查资料。

synchronized vs Lock

Tue, 06 Mar 2018 00:00:00 +0000

§2.2.1 synchronized vs Lock

考察意图：能否理解synchronized和Lock的原理差异和选型依据。

回答样板：

synchronized是JVM内置锁，由monitorenter/monitorexit字节码指令实现，自动释放锁，非公平锁，适合简单同步场景。

Lock（ReentrantLock）是JDK API级别的锁，通过AQS（AbstractQueuedSynchronizer）实现，必须手动释放（finally中unlock），支持公平锁、可中断获取锁、尝试获取锁超时、多条件变量（Condition），适合复杂同步场景。

JDK 6以后synchronized做了锁升级优化——偏向锁 → 轻量级锁 → 重量级锁，单线程竞争场景下性能差距不大。

追问预判：

追问：“synchronized的锁升级过程具体是怎样的？”

无锁状态 → 偏向锁：Mark Word存储线程ID，同一线程重入不走CAS，直接判断线程ID一致 → 轻量级锁：多个线程交替竞争时，自旋CAS尝试获取锁，Mark Word存锁记录指针 → 重量级锁：自旋超过阈值（默认10次或自适应），升级为OS互斥量，线程阻塞挂起。本质是空间换时间——偏向锁和轻量级锁尽力减少内核态切换，重量级锁是兜底方案。

陷阱提示：说不清锁升级过程；以为synchronized一直是重量级锁。

ThreadLocal原理与内存泄漏

Tue, 06 Mar 2018 00:00:00 +0000

§2.2.3 ThreadLocal原理与内存泄漏

考察意图：是否理解ThreadLocal的实现原理、内存泄漏成因及规避方式。

回答样板：

每个Thread内部维护一个ThreadLocalMap，key是ThreadLocal实例的弱引用（WeakReference），value是线程持有的值。

内存泄漏原因：在线程池场景下线程复用，ThreadLocal使用完没有调用remove()时——key（ThreadLocal实例）会被GC回收（弱引用特点），但value的强引用链依然存在（Thread → ThreadLocalMap → Entry → value），导致value无法被回收，造成内存泄漏。

规范：ThreadLocal使用完必须在finally块中调用remove()。

1
2
3
4
5
6
7


ThreadLocal<Object> tl = new ThreadLocal<>();
try {
 tl.set(value);
 // 业务逻辑
} finally {
 tl.remove();
}

追问预判：

追问：“为什么ThreadLocalMap的key要设计成弱引用？”

设计为弱引用的目的是：当ThreadLocal对象不再被外部强引用时（即使用方不再需要它了），GC可以回收ThreadLocal实例，使得对应的Entry（key=null）成为无效条目。下次ThreadLocalMap调用set/get/remove时会主动清理这些key为null的Entry。如果没有这一层弱引用设计，即使外部不再使用ThreadLocal，Entry和value也会一直存活，导致更严重的内存泄漏。

陷阱提示：答不出弱引用设计意图；只知道"用ThreadLocal存用户信息"但说不清泄漏原理。

volatile深入

Tue, 06 Mar 2018 00:00:00 +0000

§2.2.2 volatile深入

考察意图：volatile是面试高频基础题。初级答"保证可见性+禁止重排序"，中极答内存屏障语义，高级能讲出实际项目中用它解决过什么并发bug。

一、volatile的两个核心作用（基础层，必须熟练）

保证可见性：一个线程修改volatile变量后，其他线程立即可见。底层通过lock前缀指令触发缓存一致性协议（MESI），写变量时强制将缓存行写回主存并使其他CPU核的缓存行失效，其他核读时必须从主存重新加载。
禁止指令重排序：通过内存屏障限制编译器和CPU的指令重排。

不保证原子性：volatile int i; i++不是原子操作（读→改→写三步），多线程并发自增仍然会丢失更新。

二、内存屏障详解（深度层，拉开分差）

内存屏障是一条CPU指令，强制在其前后的内存操作满足特定的执行顺序。Java的volatile通过JMM定义的四类屏障保证了Happens-Before语义：

屏障类型	指令	作用
LoadLoad	`Load1; LoadLoad; Load2`	保证Load1在Load2之前完成（防止读操作重排到前面的读之前）
StoreStore	`Store1; StoreStore; Store2`	保证Store1在Store2之前完成（防止写操作重排到前面的写之前）
LoadStore	`Load1; LoadStore; Store2`	保证Load1在Store2之前完成（防止写操作重排到前面的读之前）
StoreLoad	`Store1; StoreLoad; Load2`	保证Store1在Load2之前完成（防止读操作重排到前面的写之前）最重的一类屏障，同时具备其他三种效果，通常由 `mfence`或 `lock addl`指令实现

volatile的内存屏障插入策略（JMM规范）：

1
2
3
4
5
6
7
8
9


// volatile 写之前
StoreStore屏障 ← 保证volatile写之前的普通写操作对volatile写可见
// volatile 写
StoreLoad屏障 ← 保证volatile写之后的读操作不会被重排到volatile写之前

// volatile 读
LoadLoad屏障 ← 保证volatile读之后的普通读不会被重排到volatile读之前
// volatile 读
LoadStore屏障 ← 保证volatile读之后的普通写不会被重排到volatile读之前

为什么StoreLoad屏障最重？ 它要求在执行StoreLoad之后的任何Load指令前，Store缓冲区中的所有数据必须全部刷新到主存（或者至少对其他处理器可见）。在x86平台上，StoreLoad通常由 mfence（全屏障）或带lock前缀的指令实现，开销是普通指令的几十到上百倍。而LoadLoad、StoreStore、LoadStore在x86上通常无需额外指令——x86本身就是强内存模型（TSO），只允许Store-Load重排，其他重排在硬件层面已被禁止。所以在x86上，volatile的实际开销主要来自StoreLoad屏障。

三、volatile实用场景（实战层，证明你真正用过）

场景1：DCL（双重检查锁定）单例中的volatile（经典面试题）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


public class DeviceConfigManager {
 private static volatile DeviceConfigManager instance;

 public static DeviceConfigManager getInstance() {
 if (instance == null) { // ①第一次判空
 synchronized (DeviceConfigManager.class) {
 if (instance == null) { // ②第二次判空
 instance = new DeviceConfigManager(); // ③危险操作
 }
 }
 }
 return instance;
 }
}

为什么 instance必须用volatile？ 关键在第③行 new DeviceConfigManager()，这行代码在JVM层面分三步：

1
2
3


1. memory = allocate() // 分配内存空间
2. ctorInstance(memory) // 初始化对象（执行构造方法）
3. instance = memory // 将引用指向分配的内存地址

如果不用volatile，步骤2和3可能被重排成1→3→2。线程A执行 new指令时刚好走到"分配内存→赋值引用"但构造方法还没执行完（对象是半成品），线程B走到第①行 if (instance == null)发现instance非空，直接返回了一个没有初始化完成的对象——后续使用时NullPointerException或数据错乱。volatile的StoreStore屏障保证了步骤2一定在步骤3之前完成（写前插入StoreStore：ctorInstance; StoreStore; instance=memory），线程B读instance时LoadLoad屏障保证读到的对象一定是初始化完毕的。

场景2：线程安全的状态标志位（实战项目）：

安全生产平台，定位计算引擎需要定期从配置文件刷新定位参数（基站坐标、校准因子）。这个开关被多个工作线程读取、被定时任务线程修改：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


public class PositionEngine {
 // 不用volatile——reload线程改了flag，worker线程可能永远看不到
 // private boolean configChanged = true;

 // 用volatile——reload线程一改，所有worker线程下次循环立即感知
 private volatile boolean configChanged = true;
 private PositionConfig config; // 注意：config本身不是volatile

 // 定时任务线程每5分钟刷新一次
 public void reloadConfig() {
 PositionConfig newConfig = loadFromRemote(); // ①先加载完整新配置
 this.config = newConfig; // ②再赋值给config
 this.configChanged = false; // ③最后改标记
 // volatile写前的StoreStore屏障保证①②③不会重排——
 // 所以configChanged变为false时，config一定是新值
 }

 // 几十个工作线程每秒调用数千次
 public Position calcPosition(Device device) {
 if (configChanged) {
 // volatile读后的LoadLoad屏障保证——
 // 读到configChanged=true时，config一定已经是最新赋值
 updateLocalConfig(this.config);
 configChanged = false;
 }
 // ... 定位计算，用本地缓存的config，不走volatile，零开销
 }
}

这个场景volatile的妙处：配置变量 config本身不需要volatile修饰。volatile只用于 configChanged这个"开关变量"，利用volatile写前StoreStore屏障保证"先赋值config、再改标记"的写入顺序，利用volatile读后LoadLoad屏障保证"先读标记确认、再读config内容"的读取顺序。这种"volatile变量守卫普通变量"的模式比把所有变量都标volatile高效得多。

场景3：安全发布（Safe Publication）：

在物联平台设备接入时，每个设备连接对应的Handler需要持有设备基础信息。这个信息在主线程初始化，被NIO的Worker线程读取：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


public class DeviceHandler {
 private volatile DeviceInfo deviceInfo; // 必须volatile

 // 主线程启动时调用一次
 public void init(String deviceId) {
 DeviceInfo info = new DeviceInfo(deviceId); // ①构造完整对象
 info.setProtocol("modbus"); // ②设置所有属性
 info.setLocation("井下一区");
 this.deviceInfo = info; // ③发布——volatile写
 // StoreStore屏障：保证①②所有初始化在③赋值之前被所有线程可见
 }

 // Netty Worker线程读取
 public void onData(byte[] data) {
 DeviceInfo info = this.deviceInfo;
 if (info != null) {
 // LoadLoad屏障：读到的info对象一定是完整初始化的
 String protocol = info.getProtocol(); // 必然返回"modbus"，不会是null
 }
 }
}

如果没有volatile，Worker线程可能看到 deviceInfo非空（引用已赋值），但 info对象的内部属性还是初始值（构造函数未完整执行被重排），导致 getProtocol()返回null而NPE。

陷阱提示：说"volatile能保证原子性"——致命错误（i++反例）；说"所有共享变量都需要volatile"——过于暴力，性能代价大；知道四种屏障名字但说不出各自阻止什么重排；不知道DCL单例为什么必须volatile（JDK 5之前volatile语义不够强，DCL有bug）；不知道x86只需要StoreLoad屏障（LoadLoad/StoreStore/StoreLoad在x86上硬件已保证，伪共享除外）。

线程池核心参数与执行流程

Tue, 06 Mar 2018 00:00:00 +0000

§2.2.4 线程池核心参数与执行流程

考察意图：能否根据业务场景做线程池选型与调参，理解拒绝策略的差异。

回答样板：

七个核心参数：

corePoolSize——常驻线程数
maximumPoolSize——最大线程数
keepAliveTime——空闲线程存活时间（超过corePoolSize的线程）
TimeUnit——时间单位
workQueue——阻塞队列（有界/无界）
threadFactory——线程工厂（自定义线程名、是否守护线程等）
handler——拒绝策略

执行流程：提交任务 → 当前线程数 < corePoolSize → 创建核心线程执行 → 当前线程数 >= corePoolSize → 入队列等待 → 队列满 → 创建非核心线程执行 → 当前线程数 >= maximumPoolSize → 触发拒绝策略

四种拒绝策略：

策略	行为	适用场景
AbortPolicy（默认）	抛RejectedExecutionException	必须感知任务丢失的场景
CallerRunsPolicy	调用者线程执行	反向压制动，降低任务提交速度
DiscardPolicy	直接丢弃，静默失败	不重要的日志/统计任务
DiscardOldestPolicy	丢弃队列最老的未处理任务	优先处理新任务的场景

项目实战：在物联平台用线程池处理设备数据批量写入。I/O密集型任务核心线程数设为CPU核数×2，队列用有界ArrayBlockingQueue防止内存溢出。自定义ThreadFactory设置线程名前缀方便排查。拒绝策略用CallerRunsPolicy做背压。

陷阱提示：背参数但说不清业务场景下怎么选型和调参。

ArrayList vs LinkedList

Thu, 06 Mar 2008 00:00:00 +0000

§2.3.3 ArrayList vs LinkedList

考察意图：是否理解List不同实现的性能差异及工程选型判断。

回答样板：

维度	ArrayList	LinkedList
底层结构	动态数组（Object[]）	双向链表（Node）
随机访问	O(1)	O(n)——需要遍历
尾部插入	O(1)均摊（扩容时O(n)）	O(1)
头/中间插入	O(n)（需要移动元素）	头O(1)，中间O(n)——定位+O(1)插入
内存开销	连续内存，数据紧凑	每个节点额外存储prev+next指针

工程实践：实际开发中ArrayList用得更多。原因是内存连续、CPU缓存友好（缓存行预读），大多数场景下遍历性能远超LinkedList。LinkedList的优势场景是频繁头尾插入删除（如队列、栈）。日常开发90%场景ArrayList够用。

ArrayList扩容：默认初始容量10，扩容时增长为原来的1.5倍（oldCapacity + (oldCapacity >> 1)），通过Arrays.copyOf拷贝数组。

陷阱提示：不知道ArrayList扩容机制细节；说"LinkedList插入快"不考虑定位开销。

HashMap原理

Tue, 06 Jun 2006 00:00:00 +0000

§2.3.1 HashMap原理

考察意图：是否理解HashMap的数据结构演进、put流程、扩容与树化等关键机制。

回答样板：

底层结构：JDK 7：数组+链表。JDK 8：数组+链表/红黑树。

put流程：

计算key的hash值（高16位异或低16位，降低hash冲突）
定位桶：(n - 1) & hash
无冲突 → 直接放入
有冲突 → 判断equals → 相同则覆盖，不同则尾插（JDK 7是头插，JDK 8改尾插避免死链）
链表长度 > 8 且数组长度 ≥ 64 → 树化为红黑树
容量超过 threshold（capacity × loadFactor）→ 扩容

扩容机制：2倍扩容，JDK 8做了rehash优化——原hash值与oldCap按位与，结果为0留在原位，为1移到"原位置+oldCap"，省去了每次rebuild hash表的开销。

负载因子0.75：时间和空间的折中。太低（如0.5）浪费内存；太高（如1）hash冲突增加，影响查询性能。

红黑树退化：resize时如果树的节点数 ≤ 6，退化为链表。

陷阱提示：说"HashMap线程安全"；不知道树化阈值是链表长度>8且数组长度≥64两个条件缺一不可。

ConcurrentHashMap原理

Thu, 06 Apr 2006 00:00:00 +0000

§2.3.2 ConcurrentHashMap原理

考察意图：是否理解ConcurrentHashMap在JDK 7/8的演进及JDK 8的改进要点。

回答样板：

JDK 7（分段锁）：

数据结构：Segment数组 + HashEntry数组 + 链表
Segment继承ReentrantLock，默认16个Segment
理论上支持16个线程并发写（每个Segment一把锁）
并发度固定不可动态调整

JDK 8（CAS + synchronized）：

数据结构：Node数组 + 链表/红黑树
put时CAS尝试插入空桶，CAS失败则synchronized锁桶头节点再插入
锁粒度从Segment级别（一锁锁一段）细化到桶级别（一锁锁一个桶），并发度更高
扩容支持多线程并发——transferIndex分段迁移，每个线程负责一段区域的rehash
JDK 8改synchronized而非ReentrantLock的原因：JDK 6后synchronized性能足够；省去Segment对象的内存开销；锁粒度更细带来的收益远超锁机制本身的微小差异

陷阱提示：仍停留在JDK 7分段锁的理解；不知道JDK 8为什么改CAS+synchronized。