Java服务内存超阈值报警，发现「JVM占用内存超过了Xmx值」，由此问题逐渐深入，展开一次内存调优。
一、内存报警
收到Tkex服务报警，报警内容为 服务占用内存比例超过了阈值
内存报警 是一种比较危险的信号，迅速登录服务器查看服务内存情况
二、查看服务内存详情
服务内存问题，我们使用 top 命令，查看pod内存使用情况，
发现了一个奇怪的现象，Java服务启动参数，设置了-Xmx=3G，而通 top 命令的结果来看，RES = 3.65G （RES ：Resident Memory Size，即占用内存）。这里就出现了本文的标题 JVM占用内存为何会超过Xmx值？
三、排查Java内存具体占用情况
关于占用内存超过了 Xmx，第一猜想是Xmx控制的是堆内内存，可能还有部分堆外内存。为了验证猜想，首先使用 jps 命令，获取到该服务进程号，
拿到进程号后，使用 jmap命令，查询jvm内存使用情况，
图中标出的是jvm整体内存情况，这里占用内存总和也刚好是Xmx所设置的3G。所以也从侧面证明了，Xmx控制的是Jvm堆内内存。那剩下的 0.6G ，是被哪些占用呢？
这是需要查看Java服务所占用的所有内存。Java8给HotSpot VM引入了Native Memory Tracking (NMT)特性，可以用于追踪JVM的内部内存使用，一般在压测调参的时候使用，生产环境不要引入，根据Java官方文档，开启NMT会有5%－10%的性能损耗。
设置启动参数，
-XX:NativeMemoryTracking=detail
开启NMT。使用NMT查询jvm内存使用情况，执行命令
jcmd 573 VM.native_memory summary scale=MB
从NMT的结果，可以看到整个memory主要包含了Java Heap、Class、Thread、Code、GC、Internal、Symbol、Native Memory Tracking这几部分。（reserved表示应用可用的内存大小，committed表示应用正在使用的内存大小）。
上述参数说明
- Java Heap: 堆内存，即
-Xmx限制的最大堆大小的内存。 - Class：加载的类与方法信息，即metaspace，包含两部分：一是 metadata，被
-XX:MaxMetaspaceSize限制最大大小，另外是 class space，被-XX:CompressedClassSpaceSize限制最大大小 - Thread：线程与线程栈占用内存，每个线程栈占用大小受
-Xss限制，但是总大小没有限制。 - Code：JIT 即时编译后（C1 C2 编译器优化）的代码占用内存，受
-XX:ReservedCodeCacheSize限制 - GC：垃圾回收占用内存，例如垃圾回收需要的 CardTable，标记数，区域划分记录，还有标记 GC Root 等等，都需要内存。
- Internal：命令行解析，JVMTI 使用的内存，这个不受限制，一般不会很大的
- Symbol: 常量池占用的大小，字符串常量池受
-XX:StringTableSize个数限制，总内存大小不受限制 - Native Memory Tracking：内存采集本身占用的内存大小
这里也就解释了为何Jvm占用内存会超过 Xmx，Xmx只控制java heap，还有堆外、线程等占用的空间。
仔细查看NMT结果，发现Thread占用了 487 M😲
这么一算（java_heap 3g + thread 487M + 其他）整个服务所占用的 3.6g，全部找到了。
四、查清内存问题，确认调优方案
由于我们这是数据分析服务，属于低流量，并发较低。线程为何会占用这么对内存呢？这时想到了Jvm启动参数中，有一个能够控制启动的每个线程分配的内存大小。对，就是Xss。（默认JDK1.4中是256K，JDK1.5+中是1M）带着目的性去查看了配置，
发现竟然设置了 8M。在相同物理内存下，减小这个值能生成更多的线程。但无论如何，我们每个线程占用内存完全没必要分配成8M的。
将 -Xss=1M，改完后重新部署服务，再查看下NMT结果，
至此看到，已经从 487M 降到了 75M。（-_）
总结：
- Java服务除堆本身占用内存外，还会有永久代、线程 等，所以在设置Xmx时，还要为操作系统留下足够的内存
- Xss是我们比较熟悉的一个jvm参数。在设置启动参数时，要搞清楚每一个参数的意义，该参数大小不同值的影响是什么
- 工作中的一个小问题，背后一定有值得探究的知识点😁
