這篇文章具體描述了Spark Tungsten project 引入的新的內存管理機制，并且描述了一些使用細節。
前言
發現目前還沒有這方面的文章，而自己也對這塊比較好奇，所以就有了這篇內容。
分析方式基本是自下而上，也就是我們分析的線路會從最基礎內存申請到上層的使用。我們假設你對sun.misc.Unsafe 的API有一些最基本的了解。
in-heap 和 off-heap (MemoryAllocator)
首先我們看看 Tungsten 的 MemoryAllocator
off-heap => org.apache.spark.unsafe.memory.UnsafeMemoryAllocator
in-heap => org.apache.spark.unsafe.memory.HeapMemoryAllocator
off-heap 獲取內存很簡單：
long address = Platform.allocateMemory(size);
這樣就拿到內存的地址了。這是一個絕對地址，64bit 應該夠大。注意，所有的內存都需要8byte對齊。
in-heap 則是維護了一個long類型數組：
long[] array = new long[(int) (size / 8)];
然后會拿到 Platform.LONG_ARRAY_OFFSET 的地址，以及array對象的所處的相對地址，這樣就能拿到一個絕對地址了，并且進行操作了。in-heap的對象有個特點，如果發生了GC,地址可能會變化，所以我們需要一直持有array的引用。
不管 off-heap,in-heap 最終其實都是地址的管理，所以我們抽象出了一個類來描述這個信息。
org.apache.spark.unsafe.memory.MemoryBlock
一共有四個屬性：
obj 如果是off-heap,則為null。否則則為一個array數組
offset 如果是off-heap 則為絕對偏移量，否則為 Platform.LONG_ARRAY_OFFSET
pageNumber
length 申請的內存的長度，這個in/off-heap 是一致的。
內存管理器(MemoryManager)
實際的內存管理放在了兩個層次：
org.apache.spark.unsafe.memory.ExecutorMemoryManager
org.apache.spark.unsafe.memory.TaskMemoryManager
我們先分析下他們的關系，TaskMemeoryManager是針對每個Task而言的，但是這些Task都是運行在一個JVM實例上，對應的是Executor,所以內存應該由ExecutorMemoryManager統一進行管理。但是每個task需要交互，所以就讓TaskMemeoryManager來進行這種交互。這是他們的分工，設計的很漂亮。
ExecutorMemoryManager
我們先分析下ExecutorMemoryManager，該類根據你的配置，決定是使用什么樣的MemoryAllocator，默認是in-heap。你當然也可以設置啦，通過：
spark.unsafe.offHeap=true
來進行開啟off-heap 模式。
另外，如果發現你是在使用in-heap模式，則ExecutorMemoryManage 會維護一個MemoryBlock的池子，對象池，大家應該很熟悉了。那為啥只有in-heap模式有池子呢？那是因為in-heap 需要申請long[] 數組，維護一個池子，就不用到heap里反復去做申請動作了。
該類有兩個核心方法：
MemoryBlock allocate(long size)
void free(MemoryBlock memory)
看名字就知道含義了：申請內存和釋放內存。內存的單元是MemoryBlock,邏輯上是Page的概念。
TaskMemeoryManager
這個會復雜些。然而，其實也沒多復雜，好吧我又開始犯話嘮了毛病了(O(∩_∩)O)。
為了統一對in-heap,off-heap進行建模，避免上層應用要自己區分自己處理的是in-heap還是off-heap內存塊,所以這個時候就提出了一個Page的概念，并且使用邏輯地址來做指針，通過這個邏輯地址可以定位到特定一條記錄在MemoryBlock的位置。
那么邏輯地址怎么表示呢？答案是用一個Long類型(64-bit)來表示。任何一條記錄的位置都可以用一個Long來記錄。
我們先來分析復雜的，in-heap模式：
[13-bit page num][54-bit offset]
這樣就能可以表示8192個page。一個Page對應一個MemoryBlock。然后54-bit 可以表示Pb級別的，也就是說這個MemoryBlock可以是超級大的。
不過如果你還記得前文提到的in-heap模式里使用了一個long[]數組作為數據存儲的，那么long的長度最大被限制為 Int的最大值，2^32 * 8，也就是32GB。然后所有的Page加起來，大約35個TB。足夠大了 其實。
當然這里是這里的限制，在上層里，比如shuffle，可能又會有其他的限制，導致能表示的內存會更小些。這個后續的文章我會進一步闡述。
申請一個Page的流程為：
- 申請到空閑的Page number號
- 進行實際的內存分配，得到一個MemoryBlock
- 將Page number 賦給MemoryBlock
另外這個類也提供了一個不使用Page管理的方法申請內存，然后通過 allocatedNonPageMemory 對象進行追蹤。
得到MemoryBlock，就代表我們真的拿到了內存，現在我們還要做一件事情，就是把一個記錄用一個long類型表示出來,TaskMemoryManager 提供了encodePageNumberAndOffset(MemoryBlock page, long offsetInPage) 方法進行編碼，編碼的方式就是其那面提到的：
[13-bit page num][54-bit offset]
內部具體的就是一些位操作了。對應的還有各種decode方法。
你會好奇，只有offset,怎么知道一條記錄的長度的？這個長度應該也要存儲，才能還原回一條信息吧？
目前基本的做法是從offset開始，前四個字節來表示這條記錄的長度，然后后面放具體的字節數組。為了解釋這個問題，我從UnsafeShuffleExternalSorter類里扣了一段代碼出來：
獲得這條記錄的邏輯地址，也就是一個64-bit的編碼
final long recordAddress = taskMemoryManager.encodePageNumberAndOffset(dataPage, dataPagePosition);
//dataPageBaseObject 其實就是數組對象的地址，然后以他為基準， 在dataPagePosition 處寫入一個int類型數據，這個就是內容的長度。實際的內容就會放到這個位置之后
Platform.putInt(dataPageBaseObject, dataPagePosition, lengthInBytes);
//最后把數據要拷貝的實際的內存中，就需要多要4個字節了。所以這里要加回來
dataPagePosition += 4;
Platform.copyMemory( recordBaseObject, recordBaseOffset, dataPageBaseObject, dataPagePosition, lengthInBytes);
上面分析的都是in-heap。那off-heap呢？
整個流程也是一致的。區別在于 off-heap拿到的是絕對地址，不是某個頁的偏移量，為了統一處理，在進行編碼的時候，我們要通過下面的公式重新算off-heap 在page中的相對位置：
offsetInPage -= page.getBaseOffset();
這里，page.getBaseOffset()是page對應的內存塊的起始位置，也就是MemoryBlock的offset變量。如果你還記得上面off-heap申請MemoryBlock的方式，這個就是一開始拿到的偏移量。
這樣就拿到相對于MemoryBlock的相對地址了，處理起來就可以和in-heap一致了。
解析的時候，就是反過來就行了，重新得到實際的絕對地址，然后類似in-heap,往前四個字節寫長度，后面寫實際的內容。
總結
我們看到，Spark Tungsten中，內存管理機制其實還是比較簡潔明了的。了解這個本身可能用處不是很大，對于實際上層的應用，權當做好玩吧。
