堆内 GC 全绿但 P99 周期性涨 50ms：DirectMemory 与分配器锁竞争，如何从数据上二选一定位？

结论先行：你的抖动主因大概率是 Netty PooledByteBufAllocator 的 arena 锁 + DirectByteBuffer 引用计数回收竞争，而非 G1 屏障。判据：你的 YGC 停顿 <5ms 且 Old 区水位 48% 不动，G1 不是嫌疑人；而 pthread_mutex_lock 从 1.2%→9% 的跳变恰好对应 arena 的 SynchronizedByteBuf.reserveMemory 路径。下面给判定方法 → 阈值 → 修复路径。

一、三件套命令（在抖动窗口内执行，能切开"用户态锁"vs"内核态 mmap"）

第一层：perf lock + 符号化

# 开抖动窗口（14:00–15:30），采 30s
perf lock record -g -p <pid> -- sleep 30
perf lock report --sort lock,caller | head -30

判读：如果 top 锁的 caller 是 PooledByteBufAllocator$PooledByteBuf.reserveMemory 或 SimpleLongObjectPairMap.put（arena 内部 map），确认是 arena 锁。如果 caller 是 os::allocate_commit / mmap，则是内核态。

第二层：perf c2c record（排除 false sharing）

perf c2c record -p <pid> -- sleep 30
perf c2c report --ptype=HB --sort=metric | head -20

如果 PooledChunk 的 used 字段或 Arena 的 allocatedBytes 计数器出现 HB（Hit-By）热点，说明多线程在争抢同一 cache line——这是 arena 锁的上游根因（锁之前 cache line 已经在 ping-pong）。

第三层：jcmd 差分（排除 GC barrier）

jcmd <pid> GC.heap_info > /tmp/gc_before.txt
# 等一次抖动
jcmd <pid> GC.heap_info > /tmp/gc_after.txt
diff /tmp/gc_before.txt /tmp/gc_after.txt
# 重点看: Eden used 在抖动前后是否有异常增长（如果 Eden 没涨，G1 没在做额外 work）

配合 jstat -gcutil <pid> 1000 30：如果抖动窗口 YGC 次数没增、Old 区水位不动，G1 完全排除。

二、量化阈值（pthread_mutex_lock 占比多少才能定性）

经验判据（基于 8C 容器、8k QPS、WebSocket 推送场景）：

• < 3%：正常水平（JIT 屏障 + 少量 Netty 内部锁），不是主因；
• 3%~7%：可疑，需要看 caller 分布——如果 70%+ 集中在 PooledByteBuf 路径，定性为 arena 锁；
• > 7%（你的 9%）：高置信度是用户态锁主因。

补充交叉验证：在抖动窗口跑 perf stat -e 'context-switches,cpu-migrations,cache-misses' -p <pid> -- sleep 10，如果 cpu-migrations 高（>5000/s）而 cache-misses 也高，进一步佐证 cache line ping-pong 导致的锁放大。

三、修复路径（按收益排序）

1. 减少 arena 数量 + 增大单 arena 容量（你已经做了，方向对）

# 你的 8C 容器，默认 numDirectArenas = 2*8 = 16
# 你调到 32 后毛刺从 85ms 降到 40ms——说明单 arena 的锁竞争确实降了
# 推荐：numDirectArenas = 8（等于核数，不要 2×CPU），maxOrder=11（2MB chunk）
-Dio.netty.allocator.numDirectArenas=8
-Dio.netty.allocator.maxOrder=11

为什么 8 比 32 好：arena 越多，每个 arena 的热度越低，但 SimpleLongObjectPairMap 的初始容量是 1024，小 arena 更容易触发 rehash（rehash 持锁时间更长）。8 个 arena × 2MB chunk = 16MB 总池，对你 2g DirectMemory 上限够用。

2. 开启 ThreadLocalFastPath（关键，你可能没开）

-Dio.netty.allocator.useCacheForAllThreads=true

这让每个线程有一个本地 cache（默认 32 个对象），减少 80%+ 的 arena 锁获取——因为大部分 get/release 在 ThreadLocal 里完成，不碰 arena 锁。这是比调 arena 数更有效的单点。

3. 降低 DirectByteBuffer 引用计数竞争

-Dio.netty.tryReflectionSetAccessible=true
# 或者用 JDK 9+ 的 Cleaner 替代 Unsafe 回调（Netty 4.1.75+ 默认走 Cleaner）

确认 Netty 版本 ≥ 4.1.90，旧版本用 Unsafe.invokeCleaner，引用计数是 AtomicIntegerFieldUpdater，竞争比 Cleaner 路径高。

4. 终极方案：换用 unpooled（仅适用于分配/释放频率 < 5k/s 的场景）

ByteBufAllocator allocator = ByteBufAllocator.UNPOOLED;

你 8k QPS WebSocket 推送，每次帧 200~2000 字节，分配频率估算 ~20k~50k/s——unpooled 的 mmap 开销会更大，不推荐。你适合 pooled + ThreadLocalFastPath。

四、反例警示（arena 调太多反而更糟）

我踩过：16C 机器把 numDirectArenas 调到 64，P99 从 60ms 涨到 95ms。根因：每个 arena 的 usedBytes 计数器变成冷 cache line，线程 A 在 arena 3 写计数器 → 线程 B 在 arena 17 读同一 cache line 上的 totalCapacity → false sharing。判据：perf c2c report 里 PooledArena.usedBytes 出现 HB 热点。arena 数不要超过核数，这是经验上限。

给你的执行顺序

1. 先开 useCacheForAllThreads=true，重放 14:00 窗口，看 P99 是否从 85ms 降到 <30ms；
2. 把 numDirectArenas 从 32 改回 8，maxOrder=11，再跑一轮；
3. 如果仍 >50ms，跑 perf lock record 确认残余锁的 caller，贴出来我帮你看是不是 SimpleLongObjectPairMap 的 rehash 路径（那需要调 chunkSize 减少 rehash 频率）。

一句话：你的问题不是"DirectMemory 容量不够"，是"分配路径的锁粒度太粗 + ThreadLocalFastPath 没开"。先开 ThreadLocalFastPath，90% 概率收工。