Linux内核根据应用程序的要求分配内存，通常来说应用程序分配了内存但是并没有实际全部使用，为了提高性能，这部分没用的内存可以留作它用，这部分内存是属于每个进程的，内核直接回收利用的话比较麻烦，所以内核采用一种过度分配内存（over-commit memory）的办法来间接利用这部分“空闲”的内存，提高整体内存的使用效率。
一般来说这样做没有问题，但当大多数应用程序都消耗完自己的内存的时候麻烦就来了，因为这些应用程序的内存需求加起来超出了物理内存（包括swap）的容量，内核（OOM killer）必须杀掉一些进程才能腾出空间保障系统正常运行。
用银行的例子来讲可能更容易懂一些，部分人取钱的时候银行不怕，银行有足够的存款应付，当全国人民（或者绝大多数）都取钱而且每个人都想把自己钱取完的时候银行的麻烦就来了，银行实际上是没有这么多钱给大家取的，就会发生挤兑现象。
那么Java是如何获取到Host的内存信息的呢？没错就是通过/proc/meminfo来获取到的。
默认情况下，JVM的Max Heap Size是系统内存的1/4，假如我们系统是8G，那么JVM将的默认Heap≈2G。
Docker通过CGroups完成的是对内存的限制，而/proc目录是已只读形式挂载到容器中的，由于默认情况下Java压根就看不见CGroups的限制的内存大小，而默认使用/proc/meminfo中的信息作为内存信息进行启动，
这种不兼容情况会导致，如果容器分配的内存小于JVM的内存，JVM进程会被理解杀死。
一种方法解决 JVM 内存超限的问题，这种方法可以让 JVM 自动感知 docker 容器的 cgroup 限制，从而动态的调整堆内存大小。
将 Dockerfile 中启动命令参数的-Xmx256m替换为-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap，提交再次运行流水线进行构建部署。
服务部署成功后，内存上升到一定程度后，JVM 抛出了 OOM 错误，没有继续申请堆内存，看来这种方式也是有效果的。
不过，仔细观察容器的内存占用情况，可以发现容器所使用的内存仅为不到 300M，而我们对于这个容器的内存配额限制为 512M，也就是还有 200M+ 是闲置的，并不会被 JVM 利用。这个利用率，比起上文中直接设置-Xmx256m的内存利用率要低 。
推测是因为 JVM 并不会感知到自己是部署在一个 docker 容器里的，所以它把当前的环境当成一个物理内存只有 512M 的物理机，按照比例来限制自己的最大堆内存，另一部分就被闲置了。
如此看来，如果想要充分利用自己的服务器资源，还是得多花一点功夫，手动调整好-Xmx参数。
新问题：-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap后，docker没有被kill了，但fullGC很平凡，cpu大量占用在垃圾回收的工作上了。
原因：默认的xmx的值为镜像上限内存的1/4，提前fullGC。导致内存的使用率不高。
docker常见退出码
https://www.cnblogs.com/ainimore/p/12972806.html
如何防止Java超出容器内存限制？
https://www.coder.work/article/1413306
https://www.cnblogs.com/ilinuxer/p/6648681.html
Docker环境下Java应用的JVM设置
https://www.cnblogs.com/duanxz/p/10248762.html
在 Docker 里跑 Java，趟坑总结
https://my.oschina.net/shisuyun/blog/871514
容器中的JVM资源该如何被安全的限制？
https://www.kubernetes.org.cn/5005.html
如何防止Java超出容器内存限制？
https://stackoom.com/question/3WMDz/%E5%A6%82%E4%BD%95%E9%98%B2%E6%AD%A2Java%E8%B6%85%E5%87%BA%E5%AE%B9%E5%99%A8%E5%86%85%E5%AD%98%E9%99%90%E5%88%B6
