20191022-从Jenkins NativeOOM到Java8内存

我把老掉牙的Jenkins升级了，它跑了几天好好的；后来我有一个python脚本使用JenkinsAPI 0.3.9每隔2.5分钟发送约300余get请求，结果过了3天，它就挂了；当我开两个脚本时，40.5小时就挂了。(可以通过搜索Jenkins日志/var/log/jenkins/* 中字符Jenkins is fully uo and running.断定启动和终止时间)
在后续持续观察中，对外表现为:top中的RSS巨大，已经是设置的Xmx的3~4倍，显然不合理。

根据临终前的hs_xx日志和NMT看到，堆内存已经使用完，频繁full GC(这里说的不对，并没有频繁full GC，是我看错了日志，before和after我视为了两个)，通常都是运行一段时间以后(有一个月，也有四天)突然内存暴增；经过一段时间的学习了解，可能是脚本触发了JenkinsBug， 其中的JNI调用的native code导致Native OOM，它把系统内存吃完了，再也没有内存可用了，在java进程申请新内存时，申请内存失败而退出。

曾经被pass的怀疑:
1).持有大量log造成的缓存而占用内存
2).大量TIMEWAIT造成，不够查看只有500~600，最多也不超过1000个，不应占如此大内存（同时发现之前TCP的知识没有整理，又忘光了！）
3).Test Result Analyzer 造成内存泄漏，社区一直有人在提，虽然我们装了但是我们没有一直用，比如自动刷新会导致内存泄漏

开始学习了解RSS和Xmx的具体含义，为什么他们会不一致！（我期待他们约等，我甚至按照部门旧文档给Java8设置了MaxPerSize了呢！）

新的问题是什么是堆外内存，什么是JVM native memory，还有MetaSpaceSize它是属于哪里？它怎么增长？是否可以GC？什么是MaxDirectMemorySize ? Xss即栈内存的使用处于哪里？NativeMemoryTracking的用法？-XX:-UserCompressedOops and -XX:HeapBaseMiniAddress=n
hs_err_pid.log中MetaSpaceSize 内存的used,capacity,committed,reversed代表什么含义？
used capacity committed reversed

• 堆外内存
  堆外内存(off-heap)不是一个准确的叫法，不必纠结于堆外内存和Native Memory 到底谁是谁. 我看了许多网上回答，SO上有个还说MetaData在堆上的，导致我当时非常混乱，当然后来看得多了就能辨出哪个说得不对了。 64位进程的内存基本是无限使用的，native即本地，但它不会脱离于Java进程，操作系统上看到使用了常驻内存有10G，那你JVM到底怎么花费这10G内存的？为什么有4G内存在NMT中看不到去哪里了?
• NativeMemoryTracking的用法:https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html
  -XX:NativeMemoryTracking=[off | summary | detail]
  NMT要配合jcmd使用
  jcmd <pid> VM.native_memory [summary | detail | baseline | summary.diff | detail.diff | shutdown] [scale= KB | MB | GB]
  输出中各区域的意义和diff怎么看，文档中有详细的解释；他可以帮助你分析内存泄漏，但是

Enabling NMT will result in a 5-10 percent JVM performance drop and
memory usage for NMT adds 2 machine words to all malloc memory as
malloc header. NMT memory usage is also tracked by NMT.

但是NMT不记录非JVM申请的内存，所以native code 内存泄漏它分析不出

Since NMT doesn’t track memory allocations by non-JVM code, you may have to use tools supported by the operating system to detect memory leaks in native code.

通过NMT的输出，它把JVM使用的内存分成了 ‘Java Heap’、Class、Thread、 Code、 GC、 Compiler、 Internal、 Symbol、 ‘Memory Tracking’、 ‘Pooled Free Chunks’、 ‘Unknown’ 。Unknown 是NMT对CMS垃圾回收器支持不好。对于这几部分的解释:https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr022.html#BABCBGFA

• 为啥使用-XX:+UseCompressOops后，使用32位地址可以让堆最大到32GB？2³²=4GB呀因为默认Java对象是8字节对齐的，(比如从1 000b表示第一个对象,10 000b表示第二个对象)所以表示地址时后三位可以省去，于是计算大小是就多出了3位，2³⁶=32GB https://stackoverflow.com/questions/13549787/can-i-use-more-heap-than-32-gb-with-compressed-oops

• Metaspaces
  是元数据的意思，Java8 新引入来代替 perm，默认起始有22M左右，它的大小根据下图中两个Ratio自动调整,它是受垃圾回收器管理的，但是它不在堆上；committed即提交的内存，如果主机没有开swap的话，提交的内存应该都在内存中，即真正占用了主机内存就是这么多；reversed预订（保留）的内存，即Xmx，used,capacity没看到啊？？(2022年3月 used、capacity可以通过 jmap -heap pgrep java查看)其中used是真正使用的内存，capacity 是指容量 committd是指你假笨:http://lovestblog.cn/blog/2016/10/29/metaspace/ Dzone上对Metaspace和perm的对比：https://dzone.com/articles/java-8-permgen-metaspace - Java8 X和XX参数说 明 trubleshotting https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
  https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/index.html

• NativeMemory的问题 DirectMemorySize
  默认的MaxDirectMemorySize和Xmx一样大，SO:https://stackoverflow.com/questions/3773775/default-for-xxmaxdirectmemorysize/54447744#54447744
  推荐阅读 https://dzone.com/articles/troubleshooting-problems-with-native-off-heap-memo
  中文小碟补充 https://www.cnblogs.com/duanxz/archive/2012/08/09/2630284.html

• jcmd的用法:https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr006.html#BABEHABG

• 搜索过程中遇到的其他类似问题：
  java在容器中，docker stat 、 top内存使用和 NMT committed 内存不等问题
  是docker的一个bug， 推荐阅读 https://stackoverflow.com/questions/38597965/difference-between-resident-set-size-rss-and-java-total-committed-memory-nmt
  jrockit GC和内存
  https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/garbage_collect.html
  OutOfMemoryError:https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html
  JVM outOfMemory 推荐阅读
  https://www.techpaste.com/2012/07/steps-debugdiagnose-memory-memory-leaks-jvm/
  JVM内存管理 推荐阅读-可以翻译
  https://betsol.com/2017/06/java-memory-management-for-java-virtual-machine-jvm/
  推荐阅读，从为何JVM(或者普遍的程序)不把没使用的内存还给OS到怎样强制JVM退还内存 (一个进程退还了内存影响到其它程序; CMS和G1的Major GC也会暂停JVM)
  https://blog.madadipouya.com/2019/01/04/jvm-does-not-release-memory/
  GC日志中Allocate Failure 啥意思
  https://stackoverflow.com/questions/28342736/java-gc-allocation-failure
  一般是MinorGC发生的标志

  NativeOOM-Dzone HeapByteBuffers ‘GLIBC Allocator’
  2020102 23:47 我根据下面这篇文章， 下载了Jxray，对dump的内存进行分析，发现DirectByteBuffer并没有占用很大 Native Memory，为了验证，我设置了-Djava.nio.directByteBufferSize，发现并没有起作用；文章中称，DirectByteBuffer的使用在NMT的internal中可以看到，有待考察，同时根据我的观察DirectByteBuffer小于internal大小 。现在几乎走投无路了，我取消了NMT，下面文章中一句话很经典，即使是堆外内存，在dump的堆中也能看出些蛛丝马迹，而我现在对dump文件的解读技能为零。同时对于GLIBC Allocator我我现在认为 它只能缓解问题发生但不能解决根本问题。 另一个问题是，AWS对R型机器做了什么优化，使得他声称R4是内存优化型主机？ 同时Jxray使用时注意限制堆内存大小，它的胃口很大，默认Xmx12G，刚开始脚本都没起起来报错了我还以为是它的分析结果，file cache size:3.6G，和我丢失的内存大小差不多，联想到Jenkins的日志缓存，还激动了一小阵，想想真好笑。
  https://dzone.com/articles/troubleshooting-problems-with-native-off-heap-memo
  向OS进发:
  查看pmap的内容
  http://lysu.github.io/blog/2015/02/02/how-to-deal-with-non-heap-or-native-memory-leak/
  dump整个内存: gdb的gcore gcore -a

20200112
从dump的堆中来看，有400M左右的ref.finalizer, 现在怀疑是CPU资源不足，堆内存设置过大，full GC 频率过低(看过一次日志，运行了四天，21次full GC)，导致finalizer清理线程没有及时清理持有的native memory，而请求频率高导致finaliable对象产生速率快，造成堆JVM整个内存过高，那么这个内存是属于哪里的呢？怎么控制？我如何核实？ 关于finalizer: https://www.cnblogs.com/benwu/articles/5812903.html？ ：

关于finalize: http://www.enyo.de/fw/notes/java-gc-finalizers.html
2022.03.10
查看一个正在运行的JVM的参数 jcmd pid VM.flags
触发一次GC（完全等价于代码中运行System.gc()）jcmd pid GC.run
查看一个正在运行的JVM的堆信息与垃圾回收器 jmap -heap pid
查看JVM GC原因：jstat -gccause pid 1000 每1000ms查看一次
使用NMT：-XX:+NativeMemoryTraking=detail jcmd pid VM.native_memory
当前JDK的默认参数 java -XX:+PrintFlagsFinal -version
修改运行中JVM参数 jinfo -flag flag_key=flag_value