netty4.0源码分析之PooledByteBufAllocator

概述

netty 内存管理的高性能主要依赖于两个关键点：

内存的池化管理
使用堆外直接内存（Direct Memory）

从netty 4开始，netty加入了内存池管理，采用内存池管理比普通的new ByteBuf性能提高了数十倍。
首先介绍PoolChunk, 该类主要负责内存块的分配与回收，首先来看看两个重要的术语：
page: 可以分配的最小的内存块单位。
chunk: 一堆page的集合。
下面一张图直观的表述了PoolChunk是如何管理内存的：

上图中是一个默认大小的chunk, 由2048个page组成了一个chunk，一个page的大小为8192, chunk之上有11层节点，最后一层节点数与page数量相等。每次内存分配需要保证内存的连续性，这样才能简单的操作分配到的内存，因此这里构造了一颗完整的平衡二叉树，所有子节点的管理的内存也属于其父节点。如果想获取一个8K的内存，则只需在第11层找一个可用节点即可，而如果需要16K的数据，则需要在第10层找一个可用节点，因为需要两个第11层节点。如果一个节点存在一个已经被分配的子节点，则该节点不能被分配，例如需要16K内存，这个时候id=2048的节点已经被分配，id=2049的节点未分配，就不能直接分配1024这个节点，因为这个节点下的内存只有8K了。
通过上面这个树结构，可以看到每次内存分配都是8K*(2^n), 比如需要24K内存时，实际上会申请到一块32K的内存。为了分配一个大小为chunkSize/(2^i)的内存段，需要在深度为i的层从左开始查找可用节点。如想分配16K的内存，chunkSize = 16M( 2048个page * 8K ), 则i=10, 需要从第10层找一个空闲的节点分配内存。

负责内存分配的PoolChunk类，它最小的分配单位为page, 而默认的page size为8K。在实际的应用中，会存在很多小块内存的分配，如果小块内存也占用一个page明显很浪费，针对这种情况，可以将8K的page拆成更小的块，这已经超出chunk的管理范围了，这个时候就出现了PoolSubpage, 其实PoolSubpage做的事情和PoolChunk做的事情类似，只是PoolSubpage管理的是更小的一段内存。

如上图，PoolSubpage将chunk中的一个page再次划分，分成相同大小的N份,这里暂且叫Element，通过对每一个Element的标记与清理标记来进行内存的分配与释放。

介绍了PoolChunk以及针对page的更细粒度的PoolSubpage，其实在chunk的上层还有一个管理类：PoolChunkList，PoolChunkList负责管理多个chunk的生命周期，在此基础上对内存分配进行进一步的优化。
PoolChunkList主要是为了提高内存分配的效率，每个list中包含多个chunk，而多个list又可以形成一个大的link list，在进行内存分配时，先从比较靠前的list中分配内存，这样分配到的几率更大。在高峰期申请过多的内存后，随着流量下降慢慢的释放掉多余内存，形成一个良性的循环。下图是上述三个类的层次结构：

已经讲到了内存池中的几个重要的类：
1、PoolChunk：维护一段连续内存，并负责内存块分配与回收，其中比较重要的两个概念：page:可分配的最小内存块单位；chunk:page的集合；
2、PoolSubpage：将page分为更小的块进行维护；
3、PoolChunkList：维护多个PoolChunk的生命周期。
多个PoolChunkList也会形成一个list，方便内存的管理。最终由PoolArena对这一系列类进行管理，PoolArena本身是一个抽象类，其子类为HeapArena和DirectArena，对应堆内存(heap buffer)和堆外内存(direct buffer)，除了操作的内存(byte[]和ByteBuffer)不同外两个类完全一致。

内存池内存分配流程：
1、ByteBufAllocator 准备申请一块内存；
2、尝试从PoolThreadCache中获取可用内存，如果成功则完成此次分配，否则继续往下走，注意后面的内存分配都会加锁；
3、如果是小块（可配置该值）内存分配，则尝试从PoolArena中缓存的PoolSubpage中获取内存，如果成功则完成此次分配；
4、如果是普通大小的内存分配，则从PoolChunkList中查找可用PoolChunk并进行内存分配，如果没有可用的PoolChunk则创建一个并加入到PoolChunkList中，完成此次内存分配；
5、如果是大块（大于一个chunk的大小）内存分配，则直接分配内存而不用内存池的方式；
6、内存使用完成后进行释放，释放的时候首先判断是否和分配的时候是同一个线程，如果是则尝试将其放入PoolThreadCache，这块内存将会在下一次同一个线程申请内存时使用，即前面的步骤2；
7、如果不是同一个线程，则回收至chunk中，此时chunk中的内存使用率会发生变化，可能导致该chunk在不同的PoolChunkList中移动，或者整个chunk回收（chunk在q000上，且其分配的所有内存被释放）；同时如果释放的是小块内存（与步骤3中描述的内存相同），会尝试将小块内存前置到PoolArena中，这里操作成功了，步骤3的操作中才可能成功。
在PoolThreadCache中分了tinySubPageHeapCaches、smallSubPageHeapCaches、normalSubPageHeapCaches三个数组，对应于tiny\small\normal在内存分配上的不同（tiny和small使用subpage,normal使用page）。
到此,netty内存池相关介绍已经完，netty就是实现了两个比较经典的分配策略，buddy allocation（见PoolChunk）和jemalloc（有一定改动，PooledByteBufAllocator+PoolArena+PoolChunk+PoolThreadCache)，所以如果想了解更新的信息，可以按照上面两个关键词搜索，或则看转载的原文。

netty内存池可调优参数

参数名	说明	默认值
io.netty.allocator.pageSize	page的大小	8192
io.netty.allocator.maxOrder	一个chunk的大小=pageSize << maxOrder	11
io.netty.allocator.numHeapArenas	heap arena的个数	min(cpu核数，maxMemory/chunkSize/6)，一般来说会=cpu核数
io.netty.allocator.numDirectArenas	direct arena的个数	min(cpu核数，directMemory/chunkSize/6)，一般来说会=cpu核数
io.netty.allocator.tinyCacheSize	PoolThreadCache中tiny cache每个MemoryRegionCache中的Entry个数	512
io.netty.allocator.smallCacheSize	PoolThreadCache中small cache每个MemoryRegionCache中的Entry个数	256
io.netty.allocator.normalCacheSize	PoolThreadCache中normal cache每个MemoryRegionCache中的Entry个数	64
io.netty.allocator.maxCachedBufferCapacity	PoolThreadCache中normal cache数组长度	32 * 1024
io.netty.allocator.cacheTrimInterval	PoolThreadCache中的cache收缩阈值，每隔该值次数，会进行一次收缩	8192
io.netty.allocator.type	allocator类型，如果不使用内存池，则设置为unpooled	pooled
io.netty.noUnsafe	是否关闭direct buffer	false
io.netty.leakDetectionLevel	内存泄露检测级别	SIMPLE

使用PooledByteBufAllocator

netty 基于两个维度：池化/非池化、Heap Memory/Direct Memory 的组合来确定最终使用的内存管理策略。对 netty 应用首先要能确定netty 到底采用了哪种内存管理策略，才能对各种情况下的性能表现有预期。根据 ByteBufUtil 代码：

    String allocType = SystemPropertyUtil.get("io.netty.allocator.type", PlatformDependent.isAndroid() ? "unpooled" : "pooled");allocType = allocType.toLowerCase(Locale.US).trim();ByteBufAllocator alloc;if ("unpooled".equals(allocType)) {alloc = UnpooledByteBufAllocator.DEFAULT;logger.debug("-Dio.netty.allocator.type: {}", allocType);} else if ("pooled".equals(allocType)) {alloc = PooledByteBufAllocator.DEFAULT;logger.debug("-Dio.netty.allocator.type: {}", allocType);} else {alloc = PooledByteBufAllocator.DEFAULT;logger.debug("-Dio.netty.allocator.type: pooled (unknown: {})", allocType);}

需要在 netty 应用启动时，设置 JVM参数 -Dio.netty.allocator.type=pooled 设置池化管理策略，而根据 PlatformDependent 中的代码片段:

private static final boolean DIRECT_BUFFER_PREFERRED =HAS_UNSAFE && !SystemPropertyUtil.getBoolean("io.netty.noPreferDirect", false);

ByteBufAllocator接口定义了默认的实现类

/*** Implementations are responsible to allocate buffers. Implementations of this interface are expected to be* thread-safe.*/
public interface ByteBufAllocator {ByteBufAllocator DEFAULT = ByteBufUtil.DEFAULT_ALLOCATOR;
}

只要没有设置 -Dio.netty.noPreferDirect=true 并且运行在标准 Oracle JVM（sun.misc.Unsafe存在）中，就会优先使用 Direct Memory，当然还有一个前提是分配了一定数量的Direct Memory

转载自：http://blog.csdn.net/youaremoon/article/details/47910971
http://blog.csdn.net/youaremoon/article/details/47984409
http://blog.csdn.net/youaremoon/article/details/48085591
http://blog.csdn.net/youaremoon/article/details/48184429
http://blog.csdn.net/youaremoon/article/details/50042373
http://blog.csdn.net/youaremoon/article/details/50054387

https://www.jianshu.com/p/ce7c6f5cb5f6

netty4.0源码分析之PooledByteBufAllocator相关推荐

《MapReduce 2.0源码分析与编程实战》一第1章 HBase介绍
本节书摘来异步社区<MapReduce 2.0源码分析与编程实战>一书中的第1章,作者: 王晓华责编: 陈冀康,更多章节内容可以访问云栖社区"异步社区"公众号查看. ...
Tomcat7.0源码分析——Session管理分析（下）
版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/beliefer/article/details/52451061 前言在<Tomcat7.0 ...
vue-cli 3.0 源码分析
写在前面其实最开始不是特意来研究 vue-cli 的源码,只是想了解下 node 的命令,如果想要了解 node 命令的话,那么绕不开 tj 写的 commander.js.在学习 commande ...
Tomcat7.0源码分析——Session管理分析（上）
版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/beliefer/article/details/52450268 前言对于广大java开发者而言, ...
Android6.0源码分析—— Zygote进程分析（补充）
原文地址: http://blog.csdn.net/a34140974/article/details/50915307 此博文为<Android5.0源码分析-- Zygote进程分析> ...
android6.0源码分析之Zygote进程分析
在android6.0源码分析之Runtime的初始化一文中,对Zygote进程的初期的Runtime初始化过程进行了分析,在Runtime启动结束后,会对Zygote进程进行初始化,其它Java进程 ...
android6.0源码分析之Runtime的初始化
Android运行时作为android架构的一部分,起着非常重要的作用,它和核心库(Core Libraries)组成了Android运行时库层.本文将依据android源码对AndroidRunti ...
android6.0源码分析之Camera2 HAL分析
1.Camera HAL的初始化 Camera HAL的初始加载是在Native的CameraService初始化流程中的,而CameraService初始化是在Main_mediaServer.cp ...
android6.0源码分析之Camera API2.0下的Preview(预览)流程分析
1.Camera2 preview的应用层流程分析 preview流程都是从startPreview开始的,所以来看startPreview方法的代码: <code class="hl ...
android6.0源码分析之Camera API2.0下的初始化流程分析
1.Camera2初始化的应用层流程分析 Camera2的初始化流程与Camera1.0有所区别,本文将就Camera2的内置应用来分析Camera2.0的初始化过程.Camera2.0首先启动的是C ...

netty4.0源码分析之PooledByteBufAllocator

概述

使用PooledByteBufAllocator

netty4.0源码分析之PooledByteBufAllocator相关推荐

最新文章

热门文章