生产环境中 jvm 堆大小超过 10G 是不是不太好？

（ 1 ）首先 JVM 堆都是动态分配（使用多少申请多少）/但 JVM 设置了最大申请空间(可能就是你问题中的堆不超过 X ）；
（ 2 ）当出现运行过程堆内存不够的情况：更多的是程序过于庞大（如线程过多，因为线程的栈空间是从堆空间分配），或运行深度够深导致对象迟迟得不到是释放（如递归庞大）...


JVM 默认参数都是经过大量统计数据得到较优的解，JVM 调优更多是希望单进程发挥最大的解，通常都是开发代码的限制必须调优，但为什么要写出这样的代码呢？

我这也是生产环境，不要想 dump ...

@AntonChen 那有内存泄漏时你如何发现问题？

我想问一下，你们开这么大的堆内存，生产环境上有没有实际监控过一次 FULL GC 需要花费的时间呢，恐怕都得以分钟来计吧，难道你们的业务都不需要考虑 STW 的问题？还是除了常用的 CMS 和 G1 收集器外，你们手里还有更吊的垃圾收集器？

@jones 你们生产环境一般都最大开多大堆内存？ 都是微服务，所以开的小？ 还有你们平时用 G1 吗？

@esolve 一般都是先根据硬件情况大致测算出不同堆内存的 Full GC 的停顿时间，一般应用是不允许 GC 停顿超过 1.5 秒,否则就会影响上层业务，在 1.5 秒这个范畴内去设置合理的堆内存，一般硬件上也就三四个 G 的样子， 解决 STW 的问题主要还是靠单机多进程集群的方式，比如你有 32G 的内存可以分配给 JVM 进程，如果你把这些内存一次性分配给一个 JVM 进程，那么一旦产生 FULL GC,应用可能直接停顿半分钟以上甚至一分钟，这绝对是无法接受的，所以通常应该多起几个 JVM 进程，每个进程发生 FULL GC 的时候都要控制在 1.5 秒这个范畴内，这样才不会对上层业务产生影响，开 8 个 JVM 进程每个 4G 内存 1.5 秒 FULL GC 时间明显要比单个进程 32G 内存 1 分钟 FULL GC 好的多，我说的这些都是针对停顿时间敏感的业务比如高并发的 web 应用和 API 服务，如果对停顿时间不敏感也可以只开一个进程，比如后台跑算法啊批处理作业啊爬虫啊什么的就无所谓停顿多长时间了，因为即便是 FULL GC 一次十分钟，我们也是可以接受的

@jones G1 可以调节侧重于停顿时间吧？

挖下坟

@jones 频繁 Full GC 是不允许的，我查看监控记录近三个月仅一次 Full GC 耗时 5.17s