Netty 中的內存分配淺析

時間  2020-06-13
標籤 netty 內存 分配 淺析 欄目 Netty 简体版
原文   原文鏈接

Netty 出發點做爲一款高性能的 RPC 框架必然涉及到頻繁的內存分配銷燬操做，若是是在堆上分配內存空間將會觸發頻繁的GC，JDK 在1.4以後提供的 NIO 也已經提供了直接直接分配堆外內存空間的能力，可是也僅僅是提供了基本的能力，建立、回收相關的功能和效率都很簡陋。基於此，在堆外內存使用方面，Netty 本身實現了一套建立、回收堆外內存池的相關功能。基於此咱們一塊兒來看一下 Netty 是如何實現內存分配的。java

1. Netty 中的數據容器分類

談到數據保存確定要說到內存分配，按照存儲空間來劃分，能夠分爲 堆內存 和 堆外內存；按照內存區域連貫性來劃分能夠分爲池化內存和非池化內存。這些劃分在 Netty 中的實現接口分別是：算法

按照底層存儲空間劃分：數組

  • 堆緩衝區：HeapBuffer；
  • 直接緩衝區：DirectBuffer。

按照是否池化劃分：緩存

  • 池化：PooledBuffer；
  • 非池化：UnPooledBuffer。

默認使用 PoolDireBuf 類型的內存, 這些內存主要由 PoolArea 管理。另外 Netty 並非直接對外暴露這些 API，提供了 Unsafe 類做爲出口暴露數據分配的相關操做。多線程

小知識：併發

什麼是池化？框架

通常申請內存是檢查當前內存哪裏有適合當前數據塊大小的空閒內存塊，若是有就將數據保存在當前內存塊中。高併發

那麼池化想作的事情是：既然每次來數據都要去找內存地址來存，我就先申請一塊內存地址，這一塊就是個人專用空間，內存分配、回收我全權管理。性能

池化解決的問題：this

內存碎片：

內碎片

內碎片就是申請的地址空間大於真正數據使用的內存空間。好比固定申請1M的空間做爲某個線程的使用內存，可是該線程每次最多隻佔用0.5M，那麼每次都有0.5M的碎片。若是該空間不被有效回收時間一長必然存在內存空洞。

外碎片

外碎片是指多個內存空間合併的時候發現不夠分配給待使用的空間大小。好比有一個 20byte，13byte 的連續內存空間能夠被回收，如今有一個 48byte 的數據塊須要存儲，而這兩個加起來也只有 33byte 的空間，必然不會被使用到。

如何實現內存池？

  1. 鏈表維護空閒內存地址

    最簡單的就是弄一個鏈表來維護當前空閒的內存空間地址。若是有使用就從鏈表刪除，有釋放就加入鏈表對應位置。這種方式實現簡單，可是搜索和釋放內存維護的難度仍是比較大，不太適合。

  2. 定長內存空間分配

    維護兩個列表，一個是未分配內存列表，一個是已分配內存列表。每一個內存塊都是同樣大小，分配時若是不夠就將多個塊合併到一塊兒。這種方式的缺點就是會浪費必定的內存空間，若是有特定的場景仍是沒有問題。

  3. 多段定長池分配

    在上面的定長分配基礎上，由原來的固定一個長度分配空間變爲按照不一樣對象大小(8，16，32，64，128，256，512，1k…64K)，的方式分配多個固定大小的內存池。每次要申請內存的時候按照當前對象大小去對應的池中查找是否有剩餘空間。

    Linux 自己支持動態內存分配和釋放，對應的命令爲：malloc/free。malloc 的全稱是 memory allocation，中文叫動態內存分配，用於申請一塊連續的指定大小的內存塊區域以void*類型返回分配的內存區域地址。

    malloc / free的實現過程：

    1. 空閒存儲空間以空閒鏈表的方式組織（地址遞增），每一個塊包含一個長度、一個指向下一塊的指針以及一個指向自身存儲空間的指針。（ 由於程序中的某些地方可能不經過 malloc 調用申請，所以 malloc 管理的空間不必定連續）
    2. 當有申請請求時，malloc 會掃描空閒鏈表，直到找到一個足夠大的塊爲止（首次適應）(所以每次調用malloc 時並非花費了徹底相同的時間）
    3. 若是該塊剛好與請求的大小相符，則將其從鏈表中移走並返回給用戶。若是該塊太大，則將其分爲兩部分，尾部的部分分給用戶，剩下的部分留在空閒鏈表中（更改頭部信息）。所以 malloc 分配的是一塊連續的內存。
    4. 釋放時首先搜索空閒鏈表，找到能夠插入被釋放塊的合適位置。若是與被釋放塊相鄰的任一邊是一個空閒塊，則將這兩個塊合爲一個更大的塊，以減小內存碎片。

2. Netty 中的內存分配

Netty 採用了 jemalloc 的思想，這是 FreeBSD 實現的一種併發 malloc 的算法。jemalloc 依賴多個 Arena(分配器) 來分配內存，運行中的應用都有固定數量的多個 Arena，默認的數量與處理器的個數有關。系統中有多個 Arena 的緣由是因爲各個線程進行內存分配時競爭不可避免，這可能會極大的影響內存分配的效率，爲了緩解高併發時的線程競爭，Netty 容許使用者建立多個分配器（Arena）來分離鎖，提升內存分配效率。

線程首次分配/回收內存時，首先會爲其分配一個固定的 Arena。線程選擇 Arena 時使用 round-robin 的方式，也就是順序輪流選取。

每一個線程各類保存 Arena 和緩存池信息，這樣能夠減小競爭並提升訪問效率。Arena 將內存分爲不少 Chunk 進行管理，Chunk 內部保存 Page，以頁爲單位申請。申請內存分配時，會將分配的規格分爲幾類：TINY，SAMLL，NORMAL 和 HUGE，分別對應不一樣的範圍，處理過程也不相同。

4

tiny 表明了大小在 0-512B 的內存塊；

small 表明了大小在 512B-8K 的內存塊；

normal 表明了大小在 8K-16M 的內存塊；

huge 表明了大於 16M 的內存塊。

每一個塊裏面又定義了更細粒度的單位來分配數據：

  • Chunk：一個 Chunk 的大小是 16M，Chunk 是 Netty 對操做系統進行內存申請的單位，後續全部的內存分配都是在 Chunk 裏面進行操做。
  • Page：Chunk 內部以 Page 爲單位分配內存，一個 Page 大小爲 8K。當咱們須要 16K 的空間時，Netty 就會從一個 Chunk 中找到兩個 Page 進行分配。
  • Subpage 和 element：element 是比 Page 更小的單位，當咱們申請小於 8K 的內存時，Netty 會以 element 爲單位進行內存分配。element 沒有固定大小，具體由用戶的需求決定。Netty 經過 Subpage 管理 element，Subpage 是由 Page 轉變過來的。當咱們須要 1K 的空間時，Netty 會把一個 Page 變成 Subpage，而後把 Subpage 分紅 8 個 1K 的 element 進行分配。

Chunk 中的內存分配

線程分配內存主要從兩個地方分配: PoolThreadCache 和 Arena。其中 PoolThreadCache 線程獨享, Arena 爲幾個線程共享。

5

初次申請內存的時候，Netty 會從一整塊內存（Chunk）中分出一部分來給用戶使用，這部分工做是由 Arena 來完成。而當用戶使用完畢釋放內存的時候，這些被分出來的內存會按不一樣規格大小放在 PoolThreadCache 中緩存起來。當下次要申請內存的時候，就會先從 PoolThreadCache 中找。

Chunk、Page、Subpage 和 element 都是 Arena 中的概念，Arena 的工做就是從一整塊內存中分出合適大小的內存塊。Arena 中最大的內存單位是 Chunk，這是 Netty 向操做系統申請內存的單位。而一塊 Chunk（16M） 申請下來以後，內部會被分紅 2048 個 Page（8K），當用戶向 Netty 申請超過 8K 內存的時候，Netty 會以 Page 的形式分配內存。

Chunk 內部經過夥伴算法管理 Page，具體實現爲一棵徹底平衡二叉樹：

6

二叉樹中全部子節點管理的內存也屬於其父節點。當咱們要申請大小爲 16K 的內存時，咱們會從根節點開始不斷尋找可用的節點，一直到第 10 層。那麼如何判斷一個節點是否可用呢？Netty 會在每一個節點內部保存一個值，這個值表明這個節點之下的第幾層還存在未分配的節點。好比第 9 層的節點的值若是爲 9，就表明這個節點自己到下面全部的子節點都未分配；若是第 9 層的節點的值爲 10，表明它自己不可被分配，但第 10 層有子節點能夠被分配；若是第 9 層的節點的值爲 12，此時可分配節點的深度大於了總深度，表明這個節點及其下面的全部子節點都不可被分配。下圖描述了分配的過程：

7

對於小內存（小於4096）的分配還會將 Page 細化成更小的單位 Subpage。Subpage 按大小分有兩大類：

  1. Tiny：小於 512 的狀況，最小空間爲 16，對齊大小爲 16，區間爲[16,512)，因此共有 32 種狀況。
  2. Small：大於等於 512 的狀況，總共有四種，512,1024,2048,4096。

PoolSubpage 中直接採用位圖管理空閒空間（由於不存在申請 k 個連續的空間），因此申請釋放很是簡單。

第一次申請小內存空間的時候，須要先申請一個空閒頁，而後將該頁轉成 PoolSubpage，再將該頁設爲已被佔用，最後再把這個 PoolSubpage 存到 PoolSubpage 池中。這樣下次就不須要再去申請空閒頁了，直接去池中找就行了。Netty 中有 36 種 PoolSubpage，因此用 36 個 PoolSubpage 鏈表表示 PoolSubpage 池。

由於單個 PoolChunk 只有 16M，這遠遠不夠用，因此會很不少不少 PoolChunk，這些 PoolChunk 組成一個鏈表，而後用 PoolChunkList 持有這個鏈表。

咱們先從內存分配器 PoolArena 來分析 Netty 中的內存是如何分配的，Area 的工做就是從一整塊內存中協調如何分配合適大小的內存給當前數據使用。PoolArena 是 Netty 的內存池實現抽象類，其內部子類爲 HeapArena 和 DirectArena，HeapArena 對應堆內存（heap buffer），DirectArena 對應堆外直接內存(direct buffer)，二者除了操做的內存（byte[]和ByteBuffer）不一樣外其他徹底一致。

從結構上來看，PoolArena 中主要包含三部分子內存池：

tinySubpagePools；

smallSubpagePools；

一系列的 PoolChunkList。

tinySubpagePools 和 smallSubpagePools 都是 PoolSubpage 的數組，數組長度分別爲 32 和 4。

PoolChunkList 則主要是一個容器，其內部能夠保存一系列的 PoolChunk 對象，而且，Netty 會根據內存使用率的不一樣，將 PoolChunkList 分爲不一樣等級的容器。

abstract class PoolArena<T> implements PoolArenaMetric {

   enum SizeClass {
        Tiny,
        Small,
        Normal
    }
  // 該參數指定了tinySubpagePools數組的長度，因爲tinySubpagePools每個元素的內存塊差值爲16，
	// 於是數組長度是512/16，也即這裏的512 >>> 4
  static final int numTinySubpagePools = 512 >>> 4;
	//表示該PoolArena的allocator
  final PooledByteBufAllocator parent;
  //表示PoolChunk中由Page節點構成的二叉樹的最大高度，默認11
  private final int maxOrder;
  //page的大小，默認8K
  final int pageSize;
  // 指定了葉節點大小8KB是2的多少次冪，默認爲13，該字段的主要做用是，在計算目標內存屬於二叉樹的
	// 第幾層的時候，能夠藉助於其內存大小相對於pageShifts的差值，從而快速計算其所在層數
  final int pageShifts;
  //默認16MB
  final int chunkSize;
  // 因爲PoolSubpage的大小爲8KB=8196，於是該字段的值爲
	// -8192=>=> 1111 1111 1111 1111 1110 0000 0000 0000
	// 這樣在判斷目標內存是否小於8KB時，只須要將目標內存與該數字進行與操做，只要操做結果等於0，
	// 就說明目標內存是小於8KB的，這樣就能夠判斷其是應該首先在tinySubpagePools或smallSubpagePools
	// 中進行內存申請
  final int subpageOverflowMask;
  // 該參數指定了smallSubpagePools數組的長度，默認爲4
  final int numSmallSubpagePools;
  //tinySubpagePools用來分配小於512 byte的Page
  private final PoolSubpage<T>[] tinySubpagePools;
  //smallSubpagePools用來分配大於等於512 byte且小於pageSize內存的Page
  private final PoolSubpage<T>[] smallSubpagePools;
  //用來存儲用來分配給大於等於pageSize大小內存的PoolChunk
  //存儲內存利用率50-100%的chunk
  private final PoolChunkList<T> q050;
  //存儲內存利用率25-75%的chunk
  private final PoolChunkList<T> q025;
  //存儲內存利用率1-50%的chunk
  private final PoolChunkList<T> q000;
  //存儲內存利用率0-25%的chunk
  private final PoolChunkList<T> qInit;
  //存儲內存利用率75-100%的chunk
  private final PoolChunkList<T> q075;
  //存儲內存利用率100%的chunk
  private final PoolChunkList<T> q100;
	//堆內存(heap buffer)
  static final class HeapArena extends PoolArena<byte[]> {
  
  }
   //堆外直接內存(direct buffer)
  static final class DirectArena extends PoolArena<ByteBuffer> {
    
  }
  
  
}

如上所示，PoolArena 是由多個 PoolChunk 組成的大塊內存區域，而每一個 PoolChun k則由多個 Page 組成。當須要分配的內存小於 Page 的時候，爲了節約內存採用 PoolSubpage 實現小於 Page 大小內存的分配。在PoolArena 中爲了保證 PoolChunk 空間的最大利用化，按照 PoolArena 中各 個PoolChunk 已使用的空間大小將其劃分爲 6 類：

  1. qInit：存儲內存利用率 0-25% 的 chunk；
  2. q000：存儲內存利用率 1-50% 的 chunk；
  3. q025：存儲內存利用率 25-75% 的 chunk；
  4. q050：存儲內存利用率 50-100% 的 chunk；
  5. q075：存儲內存利用率 75-100%的 chunk；
  6. q100：存儲內存利用率 100%的 chunk。

PoolArena 維護了一個 PoolChunkList 組成的雙向鏈表，每一個 PoolChunkList 內部維護了一個 PoolChunk 雙向鏈表。分配內存時，PoolArena 經過在 PoolChunkList 找到一個合適的 PoolChunk，而後從 PoolChunk 中分配一塊內存。

下面來看 PoolArena 是如何分配內存的：

private void allocate(PoolThreadCache cache, PooledByteBuf<T> buf, final int reqCapacity) {
  // 將須要申請的容量格式爲 2^N
  final int normCapacity = normalizeCapacity(reqCapacity);
  // 判斷目標容量是否小於8KB，小於8KB則使用tiny或small的方式申請內存
  if (isTinyOrSmall(normCapacity)) { // capacity < pageSize
    int tableIdx;
    PoolSubpage<T>[] table;
    boolean tiny = isTiny(normCapacity);
    // 判斷目標容量是否小於512字節，小於512字節的爲tiny類型的
    if (tiny) { // < 512
      // 將分配區域轉移到 tinySubpagePools 中
      if (cache.allocateTiny(this, buf, reqCapacity, normCapacity)) {
        // was able to allocate out of the cache so move on
        return;
      }
      // 若是沒法從當前線程緩存中申請到內存，則嘗試從tinySubpagePools中申請，這裏tinyIdx()方法
      // 就是計算目標內存是在tinySubpagePools數組中的第幾號元素中的
      tableIdx = tinyIdx(normCapacity);
      table = tinySubpagePools;
    } else {
      // 若是目標內存在512byte~8KB之間，則嘗試從smallSubpagePools中申請內存。這裏首先從
      // 當前線程的緩存中申請small級別的內存，若是申請到了，則直接返回
      if (cache.allocateSmall(this, buf, reqCapacity, normCapacity)) {
        // was able to allocate out of the cache so move on
        return;
      }
      tableIdx = smallIdx(normCapacity);
      table = smallSubpagePools;
    }
		// 獲取目標元素的頭結點
    final PoolSubpage<T> head = table[tableIdx];

    // 這裏須要注意的是，因爲對head進行了加鎖，而在同步代碼塊中判斷了s != head，
    // 也就是說PoolSubpage鏈表中是存在未使用的PoolSubpage的，由於若是該節點已經用完了，
    // 其是會被移除當前鏈表的。也就是說只要s != head，那麼這裏的allocate()方法
    // 就必定可以申請到所須要的內存塊
    synchronized (head) {
      // s != head就證實當前PoolSubpage鏈表中存在可用的PoolSubpage，而且必定可以申請到內存，
      // 由於已經耗盡的PoolSubpage是會從鏈表中移除的
      final PoolSubpage<T> s = head.next;
      // 若是此時 subpage 已經被分配過內存了執行下文，若是隻是初始化過，則跳過該分支
      if (s != head) {
        // 從PoolSubpage中申請內存
        assert s.doNotDestroy && s.elemSize == normCapacity;
        // 經過申請的內存對ByteBuf進行初始化
        long handle = s.allocate();
        assert handle >= 0;
        // 初始化 PoolByteBuf 說明其位置被分配到該區域，但此時還沒有分配內存
        s.chunk.initBufWithSubpage(buf, handle, reqCapacity);
				// 對tiny類型的申請數進行更新
        if (tiny) {
          allocationsTiny.increment();
        } else {
          allocationsSmall.increment();
        }
        return;
      }
    }
    // 走到這裏，說明目標PoolSubpage鏈表中沒法申請到目標內存塊，於是就嘗試從PoolChunk中申請
    allocateNormal(buf, reqCapacity, normCapacity);
    return;
  }
   // 走到這裏說明目標內存是大於8KB的，那麼就判斷目標內存是否大於16M，若是大於16M，
  // 則不使用內存池對其進行管理，若是小於16M，則到PoolChunkList中進行內存申請
  if (normCapacity <= chunkSize) {
    // 小於16M，首先到當前線程的緩存中申請，若是申請到了則直接返回，若是沒有申請到，
    // 則到PoolChunkList中進行申請
    if (cache.allocateNormal(this, buf, reqCapacity, normCapacity)) {
      // was able to allocate out of the cache so move on
      return;
    }
    allocateNormal(buf, reqCapacity, normCapacity);
  } else {
    // 對於大於16M的內存，Netty不會對其進行維護，而是直接申請，而後返回給用戶使用
    allocateHuge(buf, reqCapacity);
  }
}

全部內存分配的 size 都會通過 normalizeCapacity() 進行處理，申請的容量老是會被格式爲 2^N。主要規則以下：

  1. 若是目標容量小於 16 字節，則返回 16；
  2. 若是目標容量大於 16 字節，小於 512 字節，則以 16 字節爲單位，返回大於目標字節數的第一個 16 字節的倍數。好比申請的 100 字節，那麼大於 100 的 16 整數倍最低爲： 16 * 7 = 112，於是返回 112；
  3. 若是目標容量大於 512 字節，則返回大於目標容量的第一個 2 的指數冪。好比申請的 1000 字節，那麼返回的將是：2^10 = 1024。

PoolArena 提供了兩種方式進行內存分配：

  1. PoolSubpage 用於分配小於 8k 的內存

    • tinySubpagePools：用於分配小於 512 字節的內存，默認長度爲 32，由於內存分配最小爲 16，每次增長16，直到512，區間[16，512)一共有 32 個不一樣值；
    • smallSubpagePools：用於分配大於等於 512 字節的內存，默認長度爲 4；
  • tinySubpagePools 和 smallSubpagePools 中的元素默認都是 subpage。

  1. poolChunkList 用於分配大於 8k 的內存

    上面已經解釋了 q 開頭的幾個變量用於保存大於 8k 的數據。

默認先嚐試從 poolThreadCache 中分配內存，PoolThreadCache 利用 ThreadLocal 的特性，消除了多線程競爭，提升內存分配效率；

首次分配時，poolThreadCache 中並無可用內存進行分配，當上一次分配的內存使用完並釋放時，會將其加入到 poolThreadCache 中，提供該線程下次申請時使用。

若是是分配小內存，則嘗試從 tinySubpagePools 或 smallSubpagePools 中分配內存，若是沒有合適 subpage，則採用方法 allocateNormal 分配內存。

若是分配一個 page 以上的內存，直接採用方法 allocateNormal() 分配內存，allocateNormal()則會將申請動做交由 PoolChunkList 進行。

private synchronized void allocateNormal(PooledByteBuf<T> buf, int reqCapacity, int normCapacity) {
  //若是在對應的PoolChunkList能申請到內存，則返回
  if (q050.allocate(buf, reqCapacity, normCapacity) || q025.allocate(buf, reqCapacity, normCapacity) ||
      q000.allocate(buf, reqCapacity, normCapacity) || qInit.allocate(buf, reqCapacity, normCapacity) ||
      q075.allocate(buf, reqCapacity, normCapacity)) {
    ++allocationsNormal;
    return;
  }

  // Add a new chunk.
  PoolChunk<T> c = newChunk(pageSize, maxOrder, pageShifts, chunkSize);
  long handle = c.allocate(normCapacity);
  ++allocationsNormal;
  assert handle > 0;
  c.initBuf(buf, handle, reqCapacity);
  qInit.add(c);
}

首先將申請動做按照 q050->q025->q000->qInit->q075 的順序依次交由各個 PoolChunkList 進行處理，若是在對應的 PoolChunkList 中申請到了內存，則直接返回。

若是申請不到，那麼直接建立一個新的 PoolChunk，而後在該 PoolChunk 中申請目標內存，最後將該 PoolChunk 添加到 qInit 中。

上面說過 Chunk 是 Netty 向操做系統申請內存塊的最大單位，每一個 Chunk 是16M，PoolChunk 內部經過 memoryMap 數組維護了一顆徹底平衡二叉樹做爲管理底層內存分佈及回收的標記位，全部的子節點管理的內存也屬於其父節點。

關於 PoolChunk 內部如何維護徹底平衡二叉樹就不在這裏展開，你們有興趣能夠自行看源碼。

對於內存的釋放，PoolArena 主要是分爲兩種狀況，即池化和非池化，若是是非池化，則會直接銷燬目標內存塊，若是是池化的，則會將其添加到當前線程的緩存中。以下是 free()方法的源碼：

public void free(PoolChunk<T> chunk, ByteBuffer nioBuffer, long handle, int normCapacity,
     PoolThreadCache cache) {
  // 若是是非池化的，則直接銷燬目標內存塊，而且更新相關的數據
  if (chunk.unpooled) {
    int size = chunk.chunkSize();
    destroyChunk(chunk);
    activeBytesHuge.add(-size);
    deallocationsHuge.increment();
  } else {
    // 若是是池化的，首先判斷其是哪一種類型的，即tiny，small或者normal，
    // 而後將其交由當前線程的緩存進行處理，若是添加成功，則直接返回
    SizeClass sizeClass = sizeClass(normCapacity);
    if (cache != null && cache.add(this, chunk, nioBuffer, handle,
          normCapacity, sizeClass)) {
      return;
    }

    // 若是當前線程的緩存已滿，則將目標內存塊返還給公共內存塊進行處理
    freeChunk(chunk, handle, sizeClass, nioBuffer);
  }
}
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程