2. 程式人生 > >關於JVM堆外記憶體的一切

關於JVM堆外記憶體的一切

阿新 • • 發佈：2018-11-09

Java中的物件都是在JVM堆中分配的，其好處在於開發者不用關心物件的回收。但有利必有弊，堆內記憶體主要有兩個缺點：1.GC是有成本的，堆中的物件數量越多，GC的開銷也會越大。2.使用堆內記憶體進行檔案、網路的IO時，JVM會使用堆外記憶體做一次額外的中轉，也就是會多一次記憶體拷貝。

和堆內記憶體相對應，堆外記憶體就是把記憶體物件分配在Java虛擬機器堆以外的記憶體，這些記憶體直接受作業系統管理（而不是虛擬機器），這樣做的結果就是能夠在一定程度上減少垃圾回收對應用程式造成的影響。

我們先看下堆外記憶體的實現原理，再談談它的應用場景。

更多文章見個人部落格：github.com/farmerjohng…

堆外記憶體的實現

Java中分配堆外記憶體的方式有兩種，一是通過ByteBuffer.java#allocateDirect得到以一個DirectByteBuffer物件，二是直接呼叫Unsafe.java#allocateMemory分配記憶體，但Unsafe只能在JDK的程式碼中呼叫，一般不會直接使用該方法分配記憶體。

其中DirectByteBuffer也是用Unsafe去實現記憶體分配的，對堆記憶體的分配、讀寫、回收都做了封裝。本篇文章的內容也是分析DirectByteBuffer的實現。

我們從堆外記憶體的分配回收、讀寫兩個角度去分析DirectByteBuffer。

堆外記憶體的分配與回收

//ByteBuffer.java 
public static ByteBuffer allocateDirect(int capacity) {
    return new DirectByteBuffer(capacity);
}
複製程式碼

ByteBuffer#allocateDirect中僅僅是建立了一個DirectByteBuffer物件，重點在DirectByteBuffer的構造方法中。

DirectByteBuffer(int cap) {                   // package-private
    //主要是呼叫ByteBuffer的構造方法，為欄位賦值
 

    super(-1, 0, cap, cap);
    //如果是按頁對齊，則還要加一個Page的大小；我們分析只pa為false的情況就好了
    boolean pa = VM.isDirectMemoryPageAligned();
    int ps = Bits.pageSize();
    long size = Math.max(1L, (long)cap + (pa ? ps : 0));
    //嘗試釋放記憶體
    Bits.reserveMemory(size, cap);

    long base = 0;
    try {
        //分配記憶體
        base = unsafe.allocateMemory(size);
    } catch (OutOfMemoryError x) {
        Bits.unreserveMemory(size, cap);
        throw x;
    }
    //將分配的記憶體的所有值賦值為0
    unsafe.setMemory(base, size, (byte) 0);
    //為address賦值，address就是分配記憶體的起始地址，之後的資料讀寫都是以它作為基準
    if (pa && (base % ps != 0)) {
        // Round up to page boundary
        address = base + ps - (base & (ps - 1));
    } else {
        //pa為false的情況，address==base
        address = base;
    }
    //建立一個Cleaner，將this和一個Deallocator物件傳進去
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
    att = null;

}
複製程式碼

DirectByteBuffer構造方法中還做了挺多事情的，總的來說分為幾個步驟：

  1. 釋放記憶體
  2. 分配記憶體
  3. 將剛分配的記憶體空間初始化為0
  4. 建立一個cleaner物件，Cleaner物件的作用是當DirectByteBuffer物件被回收時，釋放其對應的堆外記憶體

Java的堆外記憶體回收設計是這樣的：當GC發現DirectByteBuffer物件變成垃圾時，會呼叫Cleaner#clean回收對應的堆外記憶體，一定程度上防止了記憶體洩露。當然，也可以手動的呼叫該方法，對堆外記憶體進行提前回收。

Cleaner的實現

我們先看下Cleaner#clean的實現：

public class Cleaner extends PhantomReference<Object> {
   ...
    private Cleaner(Object referent, Runnable thunk) {
        super(referent, dummyQueue);
        this.thunk = thunk;
    }
    public void clean() {
        if (remove(this)) {
            try {
                //thunk是一個Deallocator物件
                this.thunk.run();
            } catch (final Throwable var2) {
              ...
            }

        }
    }
}

private static class Deallocator
    implements Runnable
    {

        private static Unsafe unsafe = Unsafe.getUnsafe();

        private long address;
        private long size;
        private int capacity;

        private Deallocator(long address, long size, int capacity) {
            assert (address != 0);
            this.address = address;
            this.size = size;
            this.capacity = capacity;
        }

        public void run() {
            if (address == 0) {
                // Paranoia
                return;
            }
            //呼叫unsafe方法回收堆外記憶體
            unsafe.freeMemory(address);
            address = 0;
            Bits.unreserveMemory(size, capacity);
        }

    }

複製程式碼

Cleaner繼承自PhantomReference，關於虛引用的知識，可以看我之前寫的文章

簡單的說，就是當欄位referent(也就是DirectByteBuffer物件)被回收時，會呼叫到Cleaner#clean方法，最終會呼叫到Deallocator#run進行堆外記憶體的回收。

Cleaner是虛引用在JDK中的一個典型應用場景。

釋放記憶體

然後再看下DirectByteBuffer構造方法中的第二步，reserveMemory

    static void reserveMemory(long size, int cap) {
        //maxMemory代表最大堆外記憶體，也就是-XX:MaxDirectMemorySize指定的值
        if (!memoryLimitSet && VM.isBooted()) {
            maxMemory = VM.maxDirectMemory();
            memoryLimitSet = true;
        }

        //1.如果堆外記憶體還有空間，則直接返回
        if (tryReserveMemory(size, cap)) {
            return;
        }
		//走到這裡說明堆外記憶體剩餘空間已經不足了
        final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess();

        //2.堆外記憶體進行回收，最終會呼叫到Cleaner#clean的方法。如果目前沒有堆外記憶體可以回收則跳過該迴圈
        while (jlra.tryHandlePendingReference()) {
            //如果空閒的記憶體足夠了，則return
            if (tryReserveMemory(size, cap)) {
                return;
            }
        }

       //3.主動觸發一次GC，目的是觸發老年代GC
        System.gc();

        //4.重複上面的過程
        boolean interrupted = false;
        try {
            long sleepTime = 1;
            int sleeps = 0;
            while (true) {
                if (tryReserveMemory(size, cap)) {
                    return;
                }
                if (sleeps >= MAX_SLEEPS) {
                    break;
                }
                if (!jlra.tryHandlePendingReference()) {
                    try {
                        Thread.sleep(sleepTime);
                        sleepTime <<= 1;
                        sleeps++;
                    } catch (InterruptedException e) {
                        interrupted = true;
                    }
                }
            }

            //5.超出指定的次數後，還是沒有足夠記憶體，則拋異常
            throw new OutOfMemoryError("Direct buffer memory");

        } finally {
            if (interrupted) {
                // don't swallow interrupts
                Thread.currentThread().interrupt();
            }
        }
    }
	
    private static boolean tryReserveMemory(long size, int cap) {
        //size和cap主要是page對齊的區別，這裡我們把這兩個值看作是相等的
        long totalCap;
        //totalCapacity代表通過DirectByteBuffer分配的堆外記憶體的大小
        //當已分配大小<=還剩下的堆外記憶體大小時，更新totalCapacity的值返回true
        while (cap <= maxMemory - (totalCap = totalCapacity.get())) {
            if (totalCapacity.compareAndSet(totalCap, totalCap + cap)) {
                reservedMemory.addAndGet(size);
                count.incrementAndGet();
                return true;
            }
        }
		//堆外記憶體不足，返回false
        return false;
    }
複製程式碼

在建立一個新的DirecByteBuffer時，會先確認有沒有足夠的記憶體，如果沒有的話，會通過一些手段回收一部分堆外記憶體，直到可用記憶體大於需要分配的記憶體。具體步驟如下：

  1. 如果可用堆外記憶體足夠，則直接返回
  2. 呼叫tryHandlePendingReference方法回收已經變成垃圾的DirectByteBuffer物件對應的堆外記憶體，直到可用記憶體足夠，或目前沒有垃圾DirectByteBuffer物件
  3. 觸發一次full gc，其主要目的是為了防止’冰山現象‘：一個DirectByteBuffer物件本身佔用的記憶體很小，但是它可能引用了一塊很大的堆外記憶體。如果DirectByteBuffer物件進入了老年代之後變成了垃圾，因為老年代GC一直沒有觸發，導致這塊堆外記憶體也一直沒有被回收。需要注意的是如果使用引數-XX:+DisableExplicitGC，那System.gc();是無效的
  4. 重複1，2步驟的流程，直到可用記憶體大於需要分配的記憶體
  5. 如果超出指定次數還沒有回收到足夠記憶體，則OOM

詳細分析下第2步是如何回收垃圾的：tryHandlePendingReference最終呼叫到的是Reference#tryHandlePending方法，在之前的文章中有介紹過該方法

static boolean tryHandlePending(boolean waitForNotify) {
        Reference<Object> r;
        Cleaner c;
        try {
            synchronized (lock) {
                //pending由jvm gc時設定
                if (pending != null) {
                    r = pending;
                    // 如果是cleaner物件，則記錄下來
                    c = r instanceof Cleaner ? (Cleaner) r : null;
                    // unlink 'r' from 'pending' chain
                    pending = r.discovered;
                    r.discovered = null;
                } else {
                    // waitForNotify傳入的值為false
                    if (waitForNotify) {
                        lock.wait();
                    }
                    // 如果沒有待回收的Reference物件，則返回false
                    return waitForNotify;
                }
            }
        } catch (OutOfMemoryError x) {
            ...
        } catch (InterruptedException x) {
           ...
        }

        // Fast path for cleaners
        if (c != null) {
            //呼叫clean方法
            c.clean();
            return true;
        }

        ...
        return true;
}
複製程式碼

可以看到，tryHandlePendingReference的最終效果就是：如果有垃圾DirectBytebuffer物件，則呼叫對應的Cleaner#clean方法進行回收。clean方法在上面已經分析過了。

堆外記憶體的讀寫

public ByteBuffer put(byte x) {
       unsafe.putByte(ix(nextPutIndex()), ((x)));
       return this;
}

final int nextPutIndex() {                         
    if (position >= limit)
        throw new BufferOverflowException();
    return position++;
}

private long ix(int i) {
    return address + ((long)i << 0);
}

public byte get() {
    return ((unsafe.getByte(ix(nextGetIndex()))));
}

final int nextGetIndex() {                          // package-private
    if (position >= limit)
        throw new BufferUnderflowException();
    return position++;
}

複製程式碼

讀寫的邏輯也比較簡單，address就是構造方法中分配的native記憶體的起始地址。Unsafe的putByte/getByte都是native方法，就是寫入值到某個地址/獲取某個地址的值。

堆外記憶體的使用場景

適合長期存在或能複用的場景

堆外記憶體分配回收也是有開銷的，所以適合長期存在的物件

適合注重穩定的場景

堆外記憶體能有效避免因GC導致的暫停問題。

適合簡單物件的儲存

因為堆外記憶體只能儲存位元組陣列，所以對於複雜的DTO物件，每次儲存/讀取都需要序列化/反序列化，

適合注重IO效率的場景

用堆外記憶體讀寫檔案效能更好

檔案IO

關於堆外記憶體IO為什麼有更好的效能這點展開一下。

BIO

BIO的檔案寫FileOutputStream#write最終會呼叫到native層的io_util.c#writeBytes方法

void
writeBytes(JNIEnv *env, jobject this, jbyteArray bytes,
           jint off, jint len, jboolean append, jfieldID fid)
{
    jint n;
    char stackBuf[BUF_SIZE];
    char *buf = NULL;
    FD fd;

 	...

    // 如果寫入長度為0，直接返回0
    if (len == 0) {
        return;
    } else if (len > BUF_SIZE) {
        // 如果寫入長度大於BUF_SIZE（8192），無法使用棧空間buffer
        // 需要呼叫malloc在堆空間申請buffer
        buf = malloc(len);
        if (buf == NULL) {
            JNU_ThrowOutOfMemoryError(env, NULL);
            return;
        }
    } else {
        buf = stackBuf;
    }

    // 複製Java傳入的byte陣列資料到C空間的buffer中
    (*env)->GetByteArrayRegion(env, bytes, off, len, (jbyte *)buf);
 	
     if (!(*env)->ExceptionOccurred(env)) {
        off = 0;
        while (len > 0) {
            fd = GET_FD(this, fid);
            if (fd == -1) {
                JNU_ThrowIOException(env, "Stream Closed");
                break;
            }
            //寫入到檔案，這裡傳遞的陣列是我們新建立的buf
            if (append == JNI_TRUE) {
                n = (jint)IO_Append(fd, buf+off, len);
            } else {
                n = (jint)IO_Write(fd, buf+off, len);
            }
            if (n == JVM_IO_ERR) {
                JNU_ThrowIOExceptionWithLastError(env, "Write error");
                break;
            } else if (n == JVM_IO_INTR) {
                JNU_ThrowByName(env, "java/io/InterruptedIOException", NULL);
                break;
            }
            off += n;
            len -= n;
        }
    }
}

複製程式碼

GetByteArrayRegion其實就是對陣列進行了一份拷貝，該函式的實現在jni.cpp巨集定義中，找了很久才找到

//jni.cpp
JNI_ENTRY(void, \
jni_Get##Result##ArrayRegion(JNIEnv *env, ElementType##Array array, jsize start, \
             jsize len, ElementType *buf)) \
 ...
      int sc = TypeArrayKlass::cast(src->klass())->log2_element_size(); \
      //記憶體拷貝
      memcpy((u_char*) buf, \
             (u_char*) src->Tag##_at_addr(start), \
             len << sc);                          \
...
  } \
JNI_END
複製程式碼

可以看到，傳統的BIO，在native層真正寫檔案前，會在堆外記憶體（c分配的記憶體）中對位元組陣列拷貝一份，之後真正IO時，使用的是堆外的陣列。要這樣做的原因是

1.底層通過write、read、pwrite，pread函式進行系統呼叫時，需要傳入buffer的起始地址和buffer count作為引數。如果使用java heap的話，我們知道jvm中buffer往往以byte[] 的形式存在，這是一個特殊的物件，由於java heap GC的存在，這裡物件在堆中的位置往往會發生移動，移動後我們傳入系統函式的地址引數就不是真正的buffer地址了，這樣的話無論讀寫都會發生出錯。而C Heap僅僅受Full GC的影響，相對來說地址穩定。

2.JVM規範中沒有要求Java的byte[]必須是連續的記憶體空間，它往往受宿主語言的型別約束；而C Heap中我們分配的虛擬地址空間是可以連續的，而上述的系統呼叫要求我們使用連續的地址空間作為buffer。
複製程式碼

以上內容來自於 知乎 ETIN的回答 www.zhihu.com/question/60…

BIO的檔案讀也一樣，這裡就不分析了。

NIO

NIO的檔案寫最終會呼叫到IOUtil#write

 static int write(FileDescriptor fd, ByteBuffer src, long position,
                     NativeDispatcher nd, Object lock)
        throws IOException
    {
    	//如果是堆外記憶體，則直接寫
        if (src instanceof DirectBuffer)
            return writeFromNativeBuffer(fd, src, position, nd, lock);

        // Substitute a native buffer
        int pos = src.position();
        int lim = src.limit();
        assert (pos <= lim);
        int rem = (pos <= lim ? lim - pos : 0);
        //建立一塊堆外記憶體，並將資料賦值到堆外記憶體中去
        ByteBuffer bb = Util.getTemporaryDirectBuffer(rem);
        try {
            bb.put(src);
            bb.flip();
            // Do not update src until we see how many bytes were written
            src.position(pos);

            int n = writeFromNativeBuffer(fd, bb, position, nd, lock);
            if (n > 0) {
                // now update src
                src.position(pos + n);
            }
            return n;
        } finally {
            Util.offerFirstTemporaryDirectBuffer(bb);
        }
    }
    
 	/**
     * 分配一片堆外記憶體
     */
    static ByteBuffer getTemporaryDirectBuffer(int size) {
        BufferCache cache = bufferCache.get();
        ByteBuffer buf = cache.get(size);
        if (buf != null) {
            return buf;
        } else {
            // No suitable buffer in the cache so we need to allocate a new
            // one. To avoid the cache growing then we remove the first
            // buffer from the cache and free it.
            if (!cache.isEmpty()) {
                buf = cache.removeFirst();
                free(buf);
            }
            return ByteBuffer.allocateDirect(size);
        }
    }

   
複製程式碼

可以看到，NIO的檔案寫，對於堆內記憶體來說也是會有一次額外的記憶體拷貝的。

End

堆外記憶體的分析就到這裡結束了，JVM為堆外記憶體做這麼多處理，其主要原因也是因為Java畢竟不是像C這樣的完全由開發者管理記憶體的語言。因此即使使用堆外記憶體了，JVM也希望能在合適的時候自動的對堆外記憶體進行回收。

相關推薦

關於JVM堆外記憶體的一切

Java中的物件都是在JVM堆中分配的，其好處在於開發者不用關心物件的回收。但有利必有弊，堆內記憶體主要有兩個缺點：1.GC是有成本的，堆中的物件數量越多，GC的開銷也會越大。2.使用堆內記憶體進行檔案、網路的IO時，JVM會使用堆外記憶體做一次額外的中轉，也就是會多一次記憶體拷貝。 和堆內記憶體相對應，堆

學習筆記 --- JVM 堆外記憶體(off-heap)、堆內記憶體(on-heap)

堆內記憶體(on-heap) Java中分配的非空物件都是由Java虛擬機器的垃圾收集器管理的，也稱為堆內記憶體（on-heap memory）。虛擬機器會定期對垃圾記憶體進行回收，在某些特定的時間點，它會進行一次徹底的回收（full gc）。徹底回收時，垃圾收集器會對所有分配的堆內記憶體進行完

JVM堆外記憶體回收原理

今天有一個重新整理我三觀的一個觀念,開拓了我的思維,批判了我的腦回路. 今天我說天龍裡面覺得蕭峰為什麼出門自帶BGM,為什麼那麼叼.他說蕭幫主算啥,最喜歡段譽,連妹妹都不放過.我說好歹麼啥血緣關係吧,畢竟段譽是段延慶的兒子嘛,隔開三代了.他說好歹還是有關係的,

Java使用JVM堆外記憶體

package com.company; import sun.misc.Unsafe; /** * Created by yellowboy on 2017/3/9. */ public class Main3 { public static void m

解Bug之路——記一次JVM堆外記憶體洩露Bug的查詢

前言JVM的堆外記憶體洩露的定位一直是個比較棘手的問題。此次的Bug查詢從堆內記憶體的洩露反推出堆外記憶體，同時對實體記憶體的使用做了定量的分析，從而實錘了Bug的源頭。筆者將此Bug分析的過程寫成部落格，以饗讀者。由於實體記憶體定量分析部分用到了linux kernel虛擬

perftools檢視JVM堆外記憶體

最近線上執行的hbase發現分配了16g記憶體，但是實際使用了22g，堆外記憶體達到6g。感覺非常詭異。堆外記憶體用一般的工具很難檢視，可以通過google-perftools來跟蹤： http://code.google.com/p/google-perftools/d

今咱們來聊聊JVM 堆外記憶體洩露的BUG是如何查詢的

前言 JVM的堆外記憶體洩露的定位一直是個比較棘手的問題。此次的Bug查詢從堆內記憶體的洩露反推出堆外記憶體，同時對實體記憶體的使用做了定量的分析，從而實錘了Bug的源頭。筆者將此Bug分析的過程寫成部落格，以饗讀者。 由於實體記憶體定量分析部分用到了lin

解Bug之路-記一次JVM堆外記憶體洩露Bug的查詢

# 解Bug之路-記一次JVM堆外記憶體洩露Bug的查詢 ## 前言 JVM的堆外記憶體洩露的定位一直是個比較棘手的問題。此次的Bug查詢從堆內記憶體的洩露反推出堆外記憶體，同時對實體記憶體的使用做了定量的分析，從而實錘了Bug的源頭。筆者將此Bug分析的過程寫成部落格，以饗讀者。 由於實體記憶體定量分

一次完整的JVM堆外記憶體洩漏故障排查記錄

## 前言 記錄一次線上JVM堆外記憶體洩漏問題的排查過程與思路，其中夾帶一些**JVM記憶體分配機制**以及**常用的JVM問題排查指令和工具分享**，希望對大家有所幫助。 在整個排查過程中，我也走了不少彎路，但是在文章中我仍然會把完整的思路和想法寫出來，當做一次經驗教訓，給後人參考，文章最後也總結了下

JVM初探- 使用堆外記憶體減少Full GC

JVM初探-使用堆外記憶體減少Full GC 標籤 ： JVM 問題: 大部分主流網際網路企業線上Server JVM選用了CMS收集器(如Taobao、LinkedIn、Vdian), 雖然CMS可與使用者執行緒併發GC以降低STW時間, 但它

【jvm】堆外記憶體

Direct Memory是受GC控制的，例如ByteBuffer bb = ByteBuffer.allocateDirect(1024)，這段程式碼的執行會在堆外佔用1k的記憶體，Java堆內只會佔用一個物件的指標引用的大小，堆外的這1k的空間只有當bb物件被回收時，才會被回收，這裡會發現一個明顯的不對稱

JVM原始碼分析之堆外記憶體完全解讀

概述 廣義的堆外記憶體 說到堆外記憶體，那大家肯定想到堆內記憶體，這也是我們大家接觸最多的，我們在jvm引數裡通常設定-Xmx來指定我們的堆的最大值，不過這還不是我們理解的Java堆，-Xmx的值是新生代和老生代的和的最大值，我們在jvm引數裡通常還會加一個引數-XX

26、如何監控和診斷JVM堆內和堆外記憶體使用？

目錄 今天我要問你的問題是，如何監控和診斷 JVM 堆內和堆外記憶體使用？ 典型回答 考點分析 知識擴充套件 首先，堆內部是什麼結構？ 1. 新生代 2. 老年代 3. 永久代 第二，分析完堆內空間，我們一起來看看 JVM 堆外記憶體到底包括什麼？ 一課一練

從記憶體洩露、記憶體溢位和堆外記憶體，JVM優化引數配置引數

記憶體洩漏 記憶體洩漏是指程式在申請記憶體後，無法釋放已申請的記憶體空間，無用物件（不再使用的物件）持續佔有記憶體或無用物件的記憶體得不到及時釋放，從而造成記憶體空間的浪費。記憶體洩漏最終會導致OOM。 造成記憶體洩漏典型場景： 1. 單例模式的不正確使用單例物件在初始化後將在JVM的整個生命週期中以靜態變數

tsync堆外記憶體溢位排查經過

一、發生得問題 tsync服務總是莫名得宕機，java程序被莫名其妙的消失了。 二、查詢問題 當時看了系統日誌： sudo -u admin dmesg|grep -A20 kill screenshot 發現是oom了，記憶體不足被系統kill掉了。 當時懷疑有可能是堆內記憶體溢位，

Netty堆外記憶體洩露排查與總結

導讀 Netty 是一個非同步事件驅動的網路通訊層框架，用於快速開發高可用高效能的服務端網路框架與客戶端程式，它極大地簡化了 TCP 和 UDP 套接字伺服器等網路程式設計。 Netty 底層基於 JDK 的 NIO，我們為什麼不直接基於 JDK 的 NIO 或者其他NIO框架： 使用 JDK 自

Java堆外記憶體使用

JVM內部會把所有記憶體分成Java使用的堆記憶體和Native使用的記憶體，它們之間是不能共享的，就是說當你的Native記憶體用完了時，如果Java堆又有空閒記憶體，這時Native會重新向Jvm申請，而不是直接使用Java堆記憶體。 使用堆外記憶體，就是為了能直接分配和釋放記憶體，提高

Java——堆外記憶體詳解

記憶體是好東西，我們常聽堆記憶體，很多人卻不知道還有一個堆外記憶體。 那這兩個都是個啥玩意呢？且讓本帥博主今天給你好好說道說道。 一、堆內記憶體 那什麼東西是堆記憶體呢？我們來看看官方的說法。 “Java 虛擬機器具有一個堆(Heap)，堆是執行時資料區域，所

堆外記憶體的回收機制分析

1.堆外記憶體 JVM啟動時分配的記憶體，稱為堆記憶體，與之相對的，在程式碼中還可以使用堆外記憶體，比如Netty，廣泛使用了堆外記憶體，但是這部分的記憶體並不歸JVM管理，GC演算法並不會對它們進行回收，所以在使用堆外記憶體時，要格外小心，防止記憶體一直得不

Spark 堆外記憶體

轉自：https://blog.csdn.net/bitcarmanlee/article/details/78793823 1.堆外記憶體有哪些 前面提到spark中的堆記憶體溢位，除了堆記憶體，還有堆外記憶體。該部分記憶體主要用於程式的共享庫、Perm Space、 執行緒Stack和一