Java · synchronized 锁升级与对象布局

场景 1 · 锁粒度: 从"整表锁"到"分段锁"

风控规则计算, 100ms 一把大锁 → 全局串行; 按 userId 分段后并发恢复:

// 差: 全局一把锁, 无关用户互相排队
synchronized (rulesCache) { compute(user); }

// 好: 分段锁 — 不同段并行, 同段才互斥
private static final Object[] LOCKS = new Object[64];
Object lock = LOCKS[Math.floorMod(userId.hashCode(), LOCKS.length)];
synchronized (lock) { compute(user); }
// 更省心: ConcurrentHashMap<K,V>.computeIfAbsent() 内部按桶加锁, 通常不用手写

场景 2 · jstack 抓死锁

jstack <pid> | grep -A 20 "Found one Java-level deadlock"
# 输出直接给出互相等待的线程与代码行 → 调整加锁顺序(全局排序拿锁)修复
# 预防: 团队规约"多把锁必须按固定顺序获取"; 带超时的 tryLock 打破循环等待

场景 3 · JOL 亲眼看 Mark Word 变化

System.out.println(ClassLayout.parseInstance(obj).toPrintable());
// 无锁: ... 0x01 (可看到 hashcode 位)
synchronized (obj) {
    System.out.println(ClassLayout.parseInstance(obj).toPrintable());
    // 轻量级: ... 0x00 + 栈 Lock Record 指针 (JDK 15+ 无偏向, 直接轻量级)
}

场景 4 · 读多写少缓存的选型与实现

三种方案覆盖 99% 场景, 按竞争强度升级:

// 1. 低频读: synchronized 一步到位 (JIT 锁优化足够)
synchronized (map) { return map.get(k); }
# 2. 读多写少: ReadWriteLock 放行并发读
rw.readLock().lock(); try { return map.get(k); } finally { rw.readLock().unlock(); }
# 3. 读极多: StampedLock 乐观读 — 读时零锁
long stamp = sl.tryOptimisticRead();        // 不加锁, 拿版本号
V v = data; if (!sl.validate(stamp)) {    // 读期间有写? 才升级悲观读
    stamp = sl.readLock(); try { v = data; } finally { sl.unlockRead(stamp); }
}

场景 5 · tryLock 超时打破死锁

转账要同时锁两个账户, 顺序不定就有死锁风险 — 有界等待+重试是标准解:

public boolean transfer(Account from, Account to, long amt)
        throws InterruptedException {
    while (true) {
        if (from.lock.tryLock(1, SECONDS)) {
            try {
                if (to.lock.tryLock(1, SECONDS)) {
                    try { from.debit(amt); to.credit(amt); return true; }
                    finally { to.lock.unlock(); }
                }
            } finally { from.lock.unlock(); }
        }
        backoff();                    // 没拿到就退避重来, 死锁不可能形成
    }
}

场景 6 · 队列替代 wait/notify

生产者消费者自己写 wait/notify 是历史课 — BlockingQueue 三行搞定且无唤醒坑:

BlockingQueue<Order> buffer = new ArrayBlockingQueue<>(500);
# 生产者: 队满自动阻塞 (背压)
buffer.put(order);
# 消费者: 队空自动等待, 无需手动 wait/notifyAll/while 重检
Order o = buffer.take(); process(o);

场景 7 · CAS 重试 + 失败退避

无锁更新带上限退避, 避免高竞争下自旋风暴:

public static <T> boolean casRetry(AtomicReference<T> ref,
        UnaryOperator<T> update, int maxRetries) {
    for (int i = 0; i < maxRetries; i++) {
        T cur = ref.get();
        T next = update.apply(cur);
        if (ref.compareAndSet(cur, next)) return true;
        Thread.onSpinWait();            // JDK9+: 提示 CPU 让出执行资源
    }
    return false;                       // 重试耗尽: 调用方走慢路径(加锁/MQ)
}

场景 8 · JVM 锁与分布式锁的边界

synchronized 只锁进程内 — 多实例部署时同 key 并发照样穿透:

// 单实例够用: JVM 锁 (快, 无外部依赖)
synchronized (userId.intern()) { grantOnce(uid); }   // 注意: intern 词汇有限才安全
# 多实例必须: 分布式锁 + 数据库唯一约束双保险
if (redisLock.tryLock("grant:" + uid, 5s)) {
    try { dao.insertUnique(uid); }         // 最终防线是唯一索引
    catch (DuplicateKeyException e) { // 锁失效也不脏 }
    finally { redisLock.unlock(); }
}

场景 9 · 锁竞争监控与告警

BLOCKED 线程数是锁健康度的直接指标:

// 常态巡检: BLOCKED 数量与等待目标
jstack <pid> | grep -c "java.lang.Thread.State: BLOCKED"
# 告警口径: BLOCKED > 核数 且持续 1 分钟 → P2 告警
# 定位: jstack 输出里 "waiting to lock <0x...>" 对应 "locked <0x...>" 的线程栈
# 也可用 arthas: thread --state BLOCKED 一屏看全

场景 10 · Condition 多条件精准唤醒

有界缓冲区"满等空、空等满"两个条件, 一个 lock 配两个 condition:

private final ReentrantLock lock = new ReentrantLock();
private final Condition notFull  = lock.newCondition();
private final Condition notEmpty = lock.newCondition();

public void put(T x) throws InterruptedException {
    lock.lock();
    try {
        while (count == items.length) notFull.await();  // 满了等"非满"
        items[putIdx] = x; if (++putIdx == items.length) putIdx = 0;
        count++; notEmpty.signal();                    // 只叫醒等"非空"的
    } finally { lock.unlock(); }
}