netty中的PoolChunk

数据结构学的烂,看这个类比较的吃力

PoolChunk主要使用long allocate(int normCapacity) 在buffer pool中分配buffer。这个类有几个重要的概念:page:是chunk中内存分配的最小单元,chunk:表示一系列的page, 一个chunk的大小chunksize=2{maxorder}*pageSize。

首先需要分配一个长度等于chunksize的字节数组,当需要从中分配一个bytebuf时,返回一个第一个有足够空间满足这个bytebuf大小的位置。然后标记这块缓冲不可再分配了,除非该bytebuf释放。

为了在chunk中搜索满足大小的内存快的偏移,我们需要构造一个完全满二叉树,该二叉树使用byte[]存储-memoryMap,该二叉树的深度为maxOrder+1,从0开始计数,

0                                           1

1                                    2                  3

2                                4       5         6       7

3                            8    9 10  11 12  13  14 15

maxOrder

这个满二叉树,每个叶子结点标识一个page的使用状态,根结点就标识整个chunk的使用状态。 二叉树的length为2{maxorder+1}*pageSize.  [0]不存储值

在chunk中分配算法如下,如果要分配一个chunksize/2{k},我们将从第k层从左到到右中寻找未使用的节点。

memoryMap[id]=depth_of_id   =>没有使用

memoryMap[id]>depth_of_id   =>他的子结点被分配了,该结点不能分配,但是他的子结点还可以被分配。

memoryMap[id]=maxorder+1   =>子结点完全分配完了

allocateNode(d)的算法如下:

1:从root结点开始(depth=0或者id=1)

2: 如果memoryMap[1]>d 该chunk无缓冲非陪

3:如果左结点的值<=h,我们从左子树开始一直向左移动

4:否则试下右子树

时间: 2024-09-30 04:28:32

netty中的PoolChunk的相关文章

深入浅出Netty内存管理 PoolChunk

多年之前,从C内存的手动管理上升到java的自动GC,是历史的巨大进步.然而多年之后,netty的内存实现又曲线的回到了手动管理模式,正印证了马克思哲学观:社会总是在螺旋式前进的,没有永远的最好.的确,就内存管理而言,GC给程序员带来的价值是不言而喻的,不仅大大的降低了程序员的负担,而且也极大的减少了内存管理带来的Crash困扰,不过也有很多情况,可能手动的内存管理更为合适.接下去准备几个篇幅对Netty的内存管理进行深入分析.PoolChunk为了能够简单的操作内存,必须保证每次分配到的内存时

Netty中的那些坑

Netty中的那些坑(上篇) 最近开发了一个纯异步的redis客户端,算是比较深入的使用了一把netty.在使用过程中一边优化,一边解决各种坑.儿这些坑大部分基本上是Netty4对Netty3的改进部分引起的. 注:这里说的坑不是说netty不好,只是如果这些地方不注意,或者不去看netty的代码,就有可能掉进去了. 坑1: Netty 4的线程模型转变 在Netty 3的时候,upstream是在IO线程里执行的,而downstream是在业务线程里执行的.比如netty从网络读取一个包传递给

netty中使用IdleStateHandler来发起心跳

网络连接中,处理Idle事件是很常见的,一般情况下,客户端与服务端在指定时间内没有任何读写请求,就会认为连接是idle的.此时,客户端需要向服务端发送ping消息,来维持服务端与客户端的链接.那么怎么判断客户端在指定时间里没有任何读写请求呢?netty中为我们提供一个特别好用的IdleStateHandler来干这个苦差事!请看下面代码: public class EchoClient { private final static int readerIdleTimeSeconds = 40;/

【转】Netty那点事(二)Netty中的buffer

[原文]https://github.com/code4craft/netty-learning/blob/master/posts/ch2-buffer.md 上一篇文章我们概要介绍了Netty的原理及结构,下面几篇文章我们开始对Netty的各个模块进行比较详细的分析.Netty的结构最底层是buffer机制,这部分也相对独立,我们就先从buffer讲起. What:buffer二三事 buffer中文名又叫缓冲区,按照维基百科的解释,是"在数据传输时,在内存里开辟的一块临时保存数据的区域&q

Netty 中 IOException: Connection reset by peer 与 java.nio.channels.ClosedChannelException: null

最近发现系统中出现了很多 IOException: Connection reset by peer 与 ClosedChannelException: null 深入看了看代码, 做了些测试, 发现 Connection reset 会在客户端不知道 channel 被关闭的情况下, 触发了 eventloop 的 unsafe.read() 操作抛出 而 ClosedChannelException 一般是由 Netty 主动抛出的, 在 AbstractChannel 以及 SSLHand

理解Netty中的零拷贝(Zero-Copy)机制【转】

理解零拷贝 零拷贝是Netty的重要特性之一,而究竟什么是零拷贝呢? WIKI中对其有如下定义: "Zero-copy" describes computer operations in which the CPU does not perform the task of copying data from one memory area to another. 从WIKI的定义中,我们看到"零拷贝"是指计算机操作的过程中,CPU不需要为数据在内存之间的拷贝消耗资源

Netty(五)序列化protobuf在netty中的使用

protobuf是google序列化的工具,主要是把数据序列化成二进制的数据来传输用的.它主要优点如下: 1.性能好,效率高: 2.跨语言(java自带的序列化,不能跨语言) protobuf参考文档:Protobuf详解 其实,在netty中使用Protobuf需要注意的是: protobufDecoder仅仅负责编码,并不支持读半包,所以在之前,一定要有读半包的处理器. 有三种方式可以选择: 使用netty提供ProtobufVarint32FrameDecoder 继承netty提供的通用

Netty中execution包功能详解

技术点描述 Netty中关于多线程处理的代码很多(netty框架的实现本身就是异步处理机制),此文档仅针对于execution包的功能做详细解说. 以下是整个包的目录结构: 包中的调用关系如下图所示: 实现方案 参考源码包 以下是对此包中的源码的分析(请注意后四个类为此包中最重要的类) ChannelEventRunnableFilter 此接口定义了一个抽象方法: boolean filter(ChannelEventRunnable event); 如果传入的event是由Executor处

Netty中的Future

先看下Future的整个继承体系,还有一个ChannelFuture不在里面: 在并发编程中,我们通常会用到一组非阻塞的模型:Promise,Future 和 Callback.其中的 Future 表示一个可能还没有实际完成的异步任务的结果,针对这个结果可以添加 Callback 以便在任务执行成功或失败后做出对应的操作,而 Promise 交由任务执行者,任务执行者通过 Promise 可以标记任务完成或者失败. 可以说这一套模型是很多异步非阻塞架构的基础. 这一套经典的模型在 Scala.