java进程的直接内存

JAVA进程除了堆内存之外，还有一部分内存是直接内存。

直接内存并不是虚拟机运行时的数据区的一部分，也不是JAVA虚拟机规范定义的内存区域。直接内存可以被DirectByteBuffer或者Unsafe allocate申请使用。它的分配不受Java堆大小的限制，在一些场景中可以显著提高性能，避免在Java堆和Native堆中来回复制数据。如果使用不当，会触发OOM的问题，而且比较难以排查。

下面是一个申请直接内存的示例代码：

package com.jvmtest.main;

import sun.misc.Unsafe;

import java.lang.reflect.Field;

/**
 * Created by whoami on 2019/10/4.
 */
public class Main {
    private final static int _1MB = 1024*1024;

    public static void main(String[] args){
        Field unsafeField = Unsafe.class.getDeclaredFields()[0];
        unsafeField.setAccessible(true);
        try {
            Unsafe unsafe = (Unsafe)unsafeField.get(null);
            while(true){
                unsafe.allocateMemory(_1MB);
                Thread.sleep(1);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

当运行此JAVA程序时，带上NMT参数（-XX:NativeMemoryTracking=detail）。使用jcmd VM.native_memory detail打印详细信息，可以看到总的内存数目是在不断增长的：

同时，可以清晰的看到，增长比较快的区域是Internal区以及Native Memory Tracking区：

另外，最近发现一个比较奇怪的情况，就是某个JAVA进程，使用top -p pid查看时，其RSS（进程实际使用内存）存在缓慢的增长的情况（比如24小时，发现增长了2M；又过了24小时，增长了12M；又过了很长的时间，并没有增长）。增长具有不定时、偶现、和时间不成正比等特点。使用jcmd查看时，发现总的内存使用却并没有变化。目前猜测，是在某种情况下触发了内存的申请，而内存使用完毕后进程却并不会主动释放这一块内存，所以才会出现看起来top里的rss有增长，而jcmd查看总的内存使用量却没有什么变化的情况。

以下是使用jcmd vm.memory baseline设定了基线之后，打印实际内存变化情况的截图：

可以看到，实际使用的总内存（committed是小于rss中的内存的），而且与baseline比对，当前的使用内存是小于生成基线时的内存大小的（-951KB）。只要commited内存大小在baseline上下波动，那么这个程序就是比较稳定的运行的。