JVM参数之MaxDirectMemorySize

1、Java_JVM参数-XX:MaxDirectMemorySize 与 两种 ByteBuffer: heap,direct ByteBuffer（参考：https://www.cnblogs.com/laoqing/p/10380536.html）

     ByteBuffer有两种:
     heap ByteBuffer -> -XX:Xmx
     1.1、一种是heap ByteBuffer,该类对象分配在JVM的堆内存里面，直接由Java虚拟机负责垃圾回收；

     direct ByteBuffer -> -XX:MaxDirectMemorySize
     1.2、一种是direct ByteBuffer是通过jni在虚拟机外内存中分配的。通过jmap无法查看该快内存的使用情况。只能通过top来看它的内存使用情况。
           1.2.1、JVM堆内存大小可以通过-Xmx来设置，同样的direct ByteBuffer可以通过-XX:MaxDirectMemorySize来设置，此参数的含义是当Direct ByteBuffer分配的堆外内存到达指定大小后，即触发Full GC。注意该值是有上限的，默认是64M，最大为sun.misc.VM.maxDirectMemory()，在程序中中可以获得-XX:MaxDirectMemorySize的设置的值。
           1.2.2、没有配置MaxDirectMemorySize的，因此MaxDirectMemorySize的大小即等于-Xmx
           1.2.3、Direct Memory的回收机制，Direct Memory是受GC控制的
           1.2.4、对于使用Direct Memory较多的场景，需要注意下MaxDirectMemorySize的设置，避免-Xmx + Direct Memory超出物理内存大小的现象

2、用JDK8的一定要配置：-Xms -Xmx -XX:MaxDirectMemorySize，【Xmx +（加） MaxDirectMemorySize】的值不能超过docker的最大内存，不然docker内存占满了会被oomkill掉；

     没配置参数导致的问题以及处理参考：http://hellojava.info/?tag=maxdirectmemorysize （物理内存耗尽、CMS GC碎片造成RT慢的两个Case）
    分析：https://my.oschina.net/go4it/blog/3029481

3、dmesg排查消失的进程:
      3.1、适用场景：

              如果发现自己的java进程悄无声息的消失了，几乎没有留下任何线索，那么dmesg一发，很有可能有你想要的。

      3.2、具体操作
              sudo dmesg|grep -i kill | less 或者 dmesg | grep kill

　　　　  去找关键字oom_killer，找到的结果类似如下:
  　　　　[6710782.021013] java invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0, oom_scoe_adj=0 
　　　　  [6710782.070639] [] ? oom_kill_process+0x68/0x140 
　　　　  [6710782.257588] Task in /LXC011175068174 killed as a result of limit of /LXC011175068174 
　　　　  [6710784.698347] Memory cgroup out of memory: Kill process 215701 (java) score 854 or sacrifice child 
　　　　  [6710784.707978] Killed process 215701, UID 679, (java) total-vm:11017300kB, anon-rss:7152432kB, file-rss:1232kB

       以上表明，对应的java进程被系统的OOM Killer给干掉了，得分为854. 
       解释一下OOM killer（Out-Of-Memory killer），该机制会监控机器的内存资源消耗。当机器内存耗尽前，该机制会扫描所有的进程（按照一定规则计算，内存占用，时间等），挑选出得分最高的进程，然后杀死，从而保护机器。

 

       dmesg日志时间转换公式: 
       log实际时间=格林威治1970-01-01+(当前时间秒数-系统启动至今的秒数+dmesg打印的log时间)秒数：
       date -d “1970-01-01 UTC echo "$(date +%s)-$(cat /proc/uptime|cut -f 1 -d' ')+12288812.926194"|bc seconds”
       剩下的，就是看看为什么内存这么大，触发了OOM-Killer了。

4、默认情况下，VM将用于直接字节缓冲区的堆内存量限制为最大堆大小的大约85％

 http://lovestblog.cn/blog/2015/05/12/direct-buffer/

 

附：几种内存溢出处理办法：cnblogs.com/leasonWang/p/11146030.html