目錄一、前言二、API三、Netty 的數據容器3.1 工作原理四、內存池化五、字節級操作六、引用與釋放一、前言

ByteBuf是Netty當中的最重要的工具類，它與JDK的ByteBuffer原理基本上相同，也分為堆內與堆外倆種類型，但是ByteBuf做了極大的優化，具有更簡單的API，更多的工具方法和優秀的內存池設計。

二、API

Netty 的數據處理 API 通過兩個組件暴露——抽象類ByteBuf 和 接口 ByteBufHolder。

ByteBuf API 的優點：

它可以被用戶自定義的緩沖區類型擴展 通過內置的復合緩沖區類型實現了透明的零拷貝； 容量可以按需增長（類似于 JDK 的 StringBuilder） 在讀和寫這兩種模式之間切換不需要調用 ByteBuffer 的 flip()方法 讀和寫使用了不同的索引 支持方法的鏈式調用 支持引用 計數支持池化

其他類可用于管理 ByteBuf 實例的分配，以及執行各種針對于數據容器本身和它所持有的數據的操作。

三、Netty 的數據容器

所有網絡通信最終都是基于底層的字節流傳輸，因此高效、方便、易用的數據接口是迷人的，而 Netty 的 ByteBuf 生而為滿足這些需求。

3.1 工作原理

ByteBuf 維護倆不同索引：一個用于讀取，一個用于寫入：

從 ByteBuf 讀取時，其 readerIndex 將會被遞增已經被讀取的字節數 當寫入 ByteBuf 時，writerIndex 也會被遞增 一個讀索引和寫索引都設置為 0 的 16 字節 ByteBuf

這些索引兩兩之間有什么關系呢？若打算讀取字節直到 readerIndex == writerIndex，會發生啥？此時，將會到達“可讀取的”數據的末尾。類似試圖讀取超出數組末尾的數據一樣，試圖讀取超出該點的數據也會拋 IndexOutOfBoundsException。

read、write 開頭的 ByteBuf 方法，會推進對應索引 set、get 開頭的操作則不會。后面的這些方法將在作為一個參數傳入的一個相對索引上執行操作

可指定 ByteBuf 的最大容量。試圖移動寫索引（即 writerIndex）超過這個值將會觸發一個異常。（默認限制 Integer.MAX_VALUE。）

四、內存池化

非池化的堆內與堆外的 ByteBuf 示意圖

ByteBuf heapBuffer = UnpooledByteBufAllocator.DEFAULT.heapBuffer(10);ByteBuf directBuffer = UnpooledByteBufAllocator.DEFAULT.directBuffer(10);

注意要手動將GC 無法控制的非堆內存的空間釋放：

池化的堆內與堆外的 ByteBuf 示意圖

五、字節級操作

派生緩沖區

派生緩沖區為 ByteBuf 提供了以專門的方式來呈現其內容的視圖。這類視圖通過以下方法創建：

Unpooled.unmodifiableBuffer(…) order(ByteOrder) readSlice(int)

這些方法都將返回一個新的 ByteBuf 實例，但都具有自己獨立的讀、寫和標記索引。其內部存儲和 JDK 的 ByteBuffer 一樣，都是共享的。所以派生緩沖區的創建成本很低，但同時也表明若你修改了它的內容，也會同時修改對應源實例！

slice、slice(int, int)、retainedSlice、retainedSlice(int, int)

返回此緩沖區的可讀字節的一部分。此方法與buf.slice(buf.readerIndex(), buf.readableBytes())相同。該方法不會調用retain()，引用計數不會增加。retainedSlice系列方法調用類似slice().retain()，但此方法可能返回產生較少垃圾的緩沖區實現。

duplicate、retainedDuplicate

返回一個共享該緩沖區整個區域的緩沖區。此方法不會修改此緩沖區的readerIndex或writerIndex

讀取器和寫入器標記將不會重復。duplicate不會調用retain()，不會增加引用計數，而retainedDuplicate會。

readSlice、readRetainedSlice

返回部分空間，彼此共享底層緩沖區，會增加原緩沖區的readerIndex。

如果需要一個現有緩沖區的真實副本，請使用 copy()或者 copy(int, int)，因為這個調用所返回的 ByteBuf 擁有獨立的數據副本。

六、引用與釋放

ByteBuf 在使用完畢后一定要記得釋放，否則會造成內存泄露。

引用計數

通過在某個對象所持有的資源不再被其他對象引用時釋放該對象所持有的資源來優化內存使用和性能的技術。Netty 在4.x為 ByteBuf 和 ByteBufHolder 帶來了引用計數技術，都實現了：

ReferenceCounted接口

需要顯式釋放的引用計數對象。

當一個新的ReferenceCounted被實例化時，以1 作為初始值。

retain()

增加引用計數，將引用計數加1。只要引用計數>0，就能保證對象不會被釋放。

release()

減少引用計數，將引用計數減1。若引用計數減少到0 ，對象將被顯式釋放，并且訪問釋放的對象通常會導致訪問沖突。

若實現ReferenceCounted的對象是其他實現ReferenceCounted的對象的容器，則當容器的引用計數變為 0 時，所包含的對象也將通過release()被釋放。

引用計數對于池化實現（如 PooledByteBufAllocator）很重要，它降低了內存分配的開銷。

Channel channel = ...;// 從 Channel 獲取 ByteBufAllocatorByteBufAllocator allocator = channel.alloc();...// 從 ByteBufAllocator 分配一個 ByteBufByteBuf buffer = allocator.directBuffer();// 檢查引用計數是否為預期的 1assert buffer.refCnt() == 1;ByteBuf buffer = ...;// 減少該對象的活動引用。當減少到 0 時，該對象被釋放，該方法返回 trueboolean released = buffer.release();

試圖訪問一個已經被釋放的引用計數的對象，將會拋IllegalReferenceCountException

一個特定的（ReferenceCounted 的實現）類，可以用它自己的獨特方式來定義它的引用計數規則。例如可以設想一個類，其 release()方法的實現總是將引用計數設為零，而不用關心它的當前值，從而一次性使所有的活動引用都失效。

誰負責釋放

一般由最后訪問（引用計數）對象的那一方來負責將它釋放。

到此這篇關于又又???UG啦!理智分析Java NIO的ByteBuffer到底有多難用的文章就介紹到這了,更多相關Java NIO的ByteBuffer內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！