pted) {
// don't swallow interrupts
Thread.currentThread().interrupt();
}
}
}
- 六) 虽然我们看到了阻塞的原因，但是为什么jdk8下为什么就不会阻塞从4步骤中看到java 9以下是设置了DIRECT_BUFFER_CONSTRUCTOR的，因此采用的是PlatformDependent.allocateDirectNoCleaner进行内存分配。 以下是具体的介绍和关键代码
步骤一：申请内存前：通过全局内存计数器DIRECT_MEMORY_COUNTER，在每次申请内存的时候调用incrementMemoryCounter 增加相关的size，如果达到相关DIRECT_MEMORY_LIMIT(默认是-XX:MaxDirectMemorySize) 参数则直接抛出异常，而不会去同步gc等待导致大量耗时。。
步骤二：分配内存allocateDirectNoCleaner:是通过unsafe去申请内存，再用构造器DIRECT_BUFFER_CONSTRUCTOR通过内存地址和大小来构造DirectBuffer。释放也可以通过unsafe.freeMemory根据内存地址来释放相关内存，而不是通过java 自带的cleaner来释放内存。
public static ByteBuffer allocateDirectNoCleaner(int capacity) {
assert USE_DIRECT_BUFFER_NO_CLEANER;
incrementMemoryCounter(capacity);
try {
return PlatformDependent0.allocateDirectNoCleaner(capacity);
} catch (Throwable e) {
decrementMemoryCounter(capacity);
throwException(e);
return null; }
}
private static void incrementMemoryCounter(int capacity) {
if (DIRECT_MEMORY_COUNTER != null) {
long newUsedMemory = DIRECT_MEMORY_COUNTER.addAndGet(capacity);
if (newUsedMemory > DIRECT_MEMORY_LIMIT) {
DIRECT_MEMORY_COUNTER.addAndGet(-capacity);
throw new OutOfDirectMemoryError("failed to allocate " + capacity
+ " byte(s) of direct memory (used: " + (newUsedMemory - capacity)
+ ", max: " + DIRECT_MEMORY_LIMIT + ')');
}
}
}
static ByteBuffer allocateDirectNoCleaner(int capacity) {
return newDirectBuffer(UNSAFE.allocateMemory(Math.max(1, capacity)), capacity);
}
- 经过上述的源码分析，已经看到了根本原因，就是ByteBuffer.allocateDirect gc 同步等待直接内存释放导致消费能力严重不足导致的，并且在最大直接内存不足的情况下，大面积的消费阻塞耗时在申请直接内存，导致消费WriteTask能力接近于0，内存从而无法下降
总结
1.流程图：
2.直接原因：
- 跨数据中心同步数据单channel管道同步数据能力不足，导致tcp环阻塞。从而导致netty eventLoop的消费WriteTask任务(WriteAndFlush)中的write能力大于flush能力，因此申请的大量的直接内存存放在ChannelOutboundBuffer#unflushedEntry链表中没法flush。
3.根本原因：
- netty在jdk高版本需要手动添加jvm参数 -add-opens=java.base/java.nio=ALL-UNNAMED和-io.netty.tryReflectionSetAccessible 来开启采用直接调用底层unsafe来申请内存，如果不开启那么netty申请内存采用ByteBuffer.allocateDirect来申请直接内存，如果EventLoop消费任务申请的直接内存达到最大直接内存场景，那么就会导致有大量的任务消费都会同步去等待申请直接内存上。并且如果没有释放足够的直接内存，那么就会成为大面积的消费阻塞，也同时导致大量的对象累积在netty的无界队列MpscUnboundedArrayQueue中。
4.反思与定位问题慢的原因：
（1）ChannelFuture writeAndFlush(Object msg)
（2）ChannelFuture writeAndFlush(Object msg, ChannelPromise promise);
-
jdk17下监控系统看到的非堆内存监控并未与系统实际使用的直接内存统计一致，导致开始定位问题无法定位到直接内存已经达到最大值，从而并未往这个方案思考。
-
相关引用的中间件底层通信也是依赖于netty通信，如果有类似的数据同步也可能会触发类似的问题。特别ump在高版本和titan使用netty的时候是进行了shade打包的，并且相关的jvm参数也被修改，虽然不会触发该bug，但是也可能导致触发系统gc。
ump高版本：jvm参数修改（低版本直接采用了底层socket通信，未使用netty和创建ByteBuffer） io.netty.tryReflectionSetAccessible->ump.profiler.shade.io.netty.tryReflectionSetAccessible
titan：jvm参数修改:io.netty.tryReflectionSetAccessible->titan.profiler.shade.io.netty.tryReflectionSetAccessible
作者：京东零售 刘鹏
来源：京东云开发者社区 转载请注明来源