這篇“JVM堆外內存怎么實現”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“JVM堆外內存怎么實現”文章吧。
說到堆外內存，那大家肯定想到堆內內存，這也是我們大家接觸最多的，我們在jvm參數里通常設置-Xmx來指定我們的堆的最大值，不過這還不是我們理解的Java堆，-Xmx的值是新生代和老生代的和的最大值，我們在jvm參數里通常還會加一個參數-XX:MaxPermSize來指定持久代的最大值，那么我們認識的Java堆的最大值其實是-Xmx和-XX:MaxPermSize的總和，在分代算法下，新生代，老生代和持久代是連續的虛擬地址，因為它們是一起分配的，那么剩下的都可以認為是堆外內存(廣義的)了，這些包括了jvm本身在運行過程中分配的內存，codecache，jni里分配的內存，DirectByteBuffer分配的內存等等
而作為java開發者，我們常說的堆外內存溢出了，其實是狹義的堆外內存，這個主要是指java.nio.DirectByteBuffer在創建的時候分配內存，我們這篇文章里也主要是講狹義的堆外內存，因為它和我們平時碰到的問題比較密切
DirectByteBuffer通常用在通信過程中做緩沖池，在mina，netty等nio框架中屢見不鮮，先來看看JDK里的實現：
DirectByteBuffer(int cap) { // package-private
super(-1, 0, cap, cap);
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;
}
unsafe.setMemory(base, size, (byte) 0);
if (pa && (base % ps != 0)) {
// Round up to page boundary
address = base + ps - (base & (ps - 1));
} else {
address = base;
}
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
att = null;
}通過上面的構造函數我們知道，真正的內存分配是使用的Bits.reserveMemory方法
static void reserveMemory(long size, int cap) {
synchronized (Bits.class) {
if (!memoryLimitSet && VM.isBooted()) {
maxMemory = VM.maxDirectMemory();
memoryLimitSet = true;
}
// -XX:MaxDirectMemorySize limits the total capacity rather than the
// actual memory usage, which will differ when buffers are page
// aligned.
if (cap <= maxMemory - totalCapacity) {
reservedMemory += size;
totalCapacity += cap;
count++;
return;
}
}
System.gc();
try {
Thread.sleep(100);
} catch (InterruptedException x) {
// Restore interrupt status
Thread.currentThread().interrupt();
}
synchronized (Bits.class) {
if (totalCapacity + cap > maxMemory)
throw new OutOfMemoryError("Direct buffer memory");
reservedMemory += size;
totalCapacity += cap;
count++;
}
}通過上面的代碼我們知道可以通過-XX:MaxDirectMemorySize來指定最大的堆外內存，那么我們首先引入兩個問題
堆外內存默認是多大
為什么要主動調用System.gc()
如果我們沒有通過-XX:MaxDirectMemorySize來指定最大的堆外內存，那么默認的最大堆外內存是多少呢，我們還是通過代碼來分析
上面的代碼里我們看到調用了sun.misc.VM.maxDirectMemory()
private static long directMemory = 64 * 1024 * 1024;
// Returns the maximum amount of allocatable direct buffer memory.
// The directMemory variable is initialized during system initialization
// in the saveAndRemoveProperties method.
//
public static long maxDirectMemory() {
return directMemory;
}看到上面的代碼之后是不是誤以為默認的最大值是64M？其實不是的，說到這個值得從java.lang.System這個類的初始化說起
/**
* Initialize the system class. Called after thread initialization.
*/
private static void initializeSystemClass() {
// VM might invoke JNU_NewStringPlatform() to set those encoding
// sensitive properties (user.home, user.name, boot.class.path, etc.)
// during "props" initialization, in which it may need access, via
// System.getProperty(), to the related system encoding property that
// have been initialized (put into "props") at early stage of the
// initialization. So make sure the "props" is available at the
// very beginning of the initialization and all system properties to
// be put into it directly.
props = new Properties();
initProperties(props); // initialized by the VM
// There are certain system configurations that may be controlled by
// VM options such as the maximum amount of direct memory and
// Integer cache size used to support the object identity semantics
// of autoboxing. Typically, the library will obtain these values
// from the properties set by the VM. If the properties are for
// internal implementation use only, these properties should be
// removed from the system properties.
//
// See java.lang.Integer.IntegerCache and the
// sun.misc.VM.saveAndRemoveProperties method for example.
//
// Save a private copy of the system properties object that
// can only be accessed by the internal implementation. Remove
// certain system properties that are not intended for public access.
sun.misc.VM.saveAndRemoveProperties(props);
......
sun.misc.VM.booted();
}上面這個方法在jvm啟動的時候對System這個類做初始化的時候執行的，因此執行時間非常早，我們看到里面調用了sun.misc.VM.saveAndRemoveProperties(props)
public static void saveAndRemoveProperties(Properties props) {
if (booted)
throw new IllegalStateException("System initialization has completed");
savedProps.putAll(props);
// Set the maximum amount of direct memory. This value is controlled
// by the vm option -XX:MaxDirectMemorySize=<size>.
// The maximum amount of allocatable direct buffer memory (in bytes)
// from the system property sun.nio.MaxDirectMemorySize set by the VM.
// The system property will be removed.
String s = (String)props.remove("sun.nio.MaxDirectMemorySize");
if (s != null) {
if (s.equals("-1")) {
// -XX:MaxDirectMemorySize not given, take default
directMemory = Runtime.getRuntime().maxMemory();
} else {
long l = Long.parseLong(s);
if (l > -1)
directMemory = l;
}
}
// Check if direct buffers should be page aligned
s = (String)props.remove("sun.nio.PageAlignDirectMemory");
if ("true".equals(s))
pageAlignDirectMemory = true;
// Set a boolean to determine whether ClassLoader.loadClass accepts
// array syntax. This value is controlled by the system property
// "sun.lang.ClassLoader.allowArraySyntax".
s = props.getProperty("sun.lang.ClassLoader.allowArraySyntax");
allowArraySyntax = (s == null
? defaultAllowArraySyntax
: Boolean.parseBoolean(s));
// Remove other private system properties
// used by java.lang.Integer.IntegerCache
props.remove("java.lang.Integer.IntegerCache.high");
// used by java.util.zip.ZipFile
props.remove("sun.zip.disableMemoryMapping");
// used by sun.launcher.LauncherHelper
props.remove("sun.java.launcher.diag");
}如果我們通過-Dsun.nio.MaxDirectMemorySize指定了這個屬性，只要它不等于-1，那效果和加了-XX:MaxDirectMemorySize一樣的，如果兩個參數都沒指定，那么最大堆外內存的值來自于directMemory = Runtime.getRuntime().maxMemory()，這是一個native方法
JNIEXPORT jlong JNICALL
Java_java_lang_Runtime_maxMemory(JNIEnv *env, jobject this)
{
return JVM_MaxMemory();
}
JVM_ENTRY_NO_ENV(jlong, JVM_MaxMemory(void))
JVMWrapper("JVM_MaxMemory");
size_t n = Universe::heap()->max_capacity();
return convert_size_t_to_jlong(n);
JVM_END其中在我們使用CMS GC的情況下的實現如下，其實是新生代的最大值-一個survivor的大小+老生代的最大值，也就是我們設置的-Xmx的值里除去一個survivor的大小就是默認的堆外內存的大小了
size_t GenCollectedHeap::max_capacity() const {
size_t res = 0;
for (int i = 0; i < _n_gens; i++) {
res += _gens[i]->max_capacity();
}
return res;
}
size_t DefNewGeneration::max_capacity() const {
const size_t alignment = GenCollectedHeap::heap()->collector_policy()->min_alignment();
const size_t reserved_bytes = reserved().byte_size();
return reserved_bytes - compute_survivor_size(reserved_bytes, alignment);
}
size_t Generation::max_capacity() const {
return reserved().byte_size();
}既然要調用System.gc，那肯定是想通過觸發一次gc操作來回收堆外內存，不過我想先說的是堆外內存不會對gc造成什么影響(這里的System.gc除外)，但是堆外內存的回收其實依賴于我們的gc機制，首先我們要知道在java層面和我們在堆外分配的這塊內存關聯的只有與之關聯的DirectByteBuffer對象了，它記錄了這塊內存的基地址以及大小，那么既然和gc也有關，那就是gc能通過操作DirectByteBuffer對象來間接操作對應的堆外內存了。DirectByteBuffer對象在創建的時候關聯了一個PhantomReference，說到PhantomReference它其實主要是用來跟蹤對象何時被回收的，它不能影響gc決策，但是gc過程中如果發現某個對象除了只有PhantomReference引用它之外，并沒有其他的地方引用它了，那將會把這個引用放到java.lang.ref.Reference.pending隊列里，在gc完畢的時候通知ReferenceHandler這個守護線程去執行一些后置處理，而DirectByteBuffer關聯的PhantomReference是PhantomReference的一個子類，在最終的處理里會通過Unsafe的free接口來釋放DirectByteBuffer對應的堆外內存塊
JDK里ReferenceHandler的實現：
private static class ReferenceHandler extends Thread {
ReferenceHandler(ThreadGroup g, String name) {
super(g, name);
}
public void run() {
for (;;) {
Reference r;
synchronized (lock) {
if (pending != null) {
r = pending;
Reference rn = r.next;
pending = (rn == r) ? null : rn;
r.next = r;
} else {
try {
lock.wait();
} catch (InterruptedException x) { }
continue;
}
}
// Fast path for cleaners
if (r instanceof Cleaner) {
((Cleaner)r).clean();
continue;
}
ReferenceQueue q = r.queue;
if (q != ReferenceQueue.NULL) q.enqueue(r);
}
}
}可見如果pending為空的時候，會通過lock.wait()一直等在那里，其中喚醒的動作是在jvm里做的，當gc完成之后會調用如下的方法VM_GC_Operation::doit_epilogue()，在方法末尾會調用lock的notify操作，至于pending隊列什么時候將引用放進去的，其實是在gc的引用處理邏輯中放進去的，針對引用的處理后面可以專門寫篇文章來介紹
void VM_GC_Operation::doit_epilogue() {
assert(Thread::current()->is_Java_thread(), "just checking");
// Release the Heap_lock first.
SharedHeap* sh = SharedHeap::heap();
if (sh != NULL) sh->_thread_holds_heap_lock_for_gc = false;
Heap_lock->unlock();
release_and_notify_pending_list_lock();
}
void VM_GC_Operation::release_and_notify_pending_list_lock() {
instanceRefKlass::release_and_notify_pending_list_lock(&_pending_list_basic_lock);
}對于System.gc的實現，之前寫了一篇文章來重點介紹，jvm原理之SystemGC源碼分析，它會對新生代的老生代都會進行內存回收，這樣會比較徹底地回收DirectByteBuffer對象以及他們關聯的堆外內存，我們dump內存發現DirectByteBuffer對象本身其實是很小的，但是它后面可能關聯了一個非常大的堆外內存，因此我們通常稱之為『冰山對象』，我們做ygc的時候會將新生代里的不可達的DirectByteBuffer對象及其堆外內存回收了，但是無法對old里的DirectByteBuffer對象及其堆外內存進行回收，這也是我們通常碰到的最大的問題，如果有大量的DirectByteBuffer對象移到了old，但是又一直沒有做cms gc或者full gc，而只進行ygc，那么我們的物理內存可能被慢慢耗光，但是我們還不知道發生了什么，因為heap明明剩余的內存還很多(前提是我們禁用了System.gc)。
DirectByteBuffer在創建的時候會通過Unsafe的native方法來直接使用malloc分配一塊內存，這塊內存是heap之外的，那么自然也不會對gc造成什么影響(System.gc除外)，因為gc耗時的操作主要是操作heap之內的對象，對這塊內存的操作也是直接通過Unsafe的native方法來操作的，相當于DirectByteBuffer僅僅是一個殼，還有我們通信過程中如果數據是在Heap里的，最終也還是會copy一份到堆外，然后再進行發送，所以為什么不直接使用堆外內存呢。對于需要頻繁操作的內存，并且僅僅是臨時存在一會的，都建議使用堆外內存，并且做成緩沖池，不斷循環利用這塊內存。
如果我們大面積使用堆外內存并且沒有限制，那遲早會導致內存溢出，畢竟程序是跑在一臺資源受限的機器上，因為這塊內存的回收不是你直接能控制的，當然你可以通過別的一些途徑，比如反射，直接使用Unsafe接口等，但是這些務必給你帶來了一些煩惱，Java與生俱來的優勢被你完全拋棄了—開發不需要關注內存的回收，由gc算法自動去實現。另外上面的gc機制與堆外內存的關系也說了，如果一直觸發不了cms gc或者full gc，那么后果可能很嚴重。
以上就是關于“JVM堆外內存怎么實現”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
