”线上系统的JVM内存是否设置的越大越好？”乍一听到这个问题，我第一个反应就是“NO”，但是，具体为什么不行，又说不出什么所以然来。
其实，说一个东西不行，我们只要说出几个“缺点”就可以了，如果还能列举出几个反例，特别是被广泛认可或广泛采用的反例，那就更好了。
JVM并非十全十美
依赖JVM的最大的一个问题，就是STW（Stop the world，默认达到92%就会触发GC），在STW过程中，会暂停其他的工作线程，虽然GC的时间是很短暂的，但是，如果恰好在这个期间有请求过来，那可能就会无法响应这次请求。
记得有个活生生的例子，之前一家公司，我同桌，接到了一个需求：跑资讯文章。需求是比较扰人的，目的是要跑到指定数量的文章，过程是非常繁琐的，有N多个判断分支嵌套组合，比如第一个段落，它是由四句话组成的，第一句话是需要依赖A字段，假如A字段没有，那得主动去计算，如果计算不出来，那就找A字段的替代字段，如果替代字段不存在，或者不符合预期，那最后得通过公式来伪造一个近似的值。我同桌本来写代码挺不错的，结果，在服务器上跑这需求的代码，楞是让服务器短时间内多次GC，造成了严重的卡顿现象，影响了其他的业务。
依托操作系统
之前说过，操作系统有一个OS Cache，我们可以把数据存储的压力，转移到OS Cache上，这样的话，有两个好处，第一：规避了JVM复杂且耗时的GC；第二，依托操作系统级别的内存来进行读写，性能会更高。
著名的Kafka，它就是典型案列。它的高效读写，就是使用了OS Cache 和 零拷贝技术。
操作系统是不是也存在内存回收？
答案是：也存在。只不过，操作系统的内存回收，是针对“页”的，是操作系统级别的操作，效率肯定是优于JVM。而且，操作系统的内存管理，也是比JVM的内存管理更加健壮。
结论
1. 分给JVM的内存，并不是越多越好；
2. 可以把部分压力转移到OS Cache；
3. 建议给OS Cache留下2/3的内存，32G的机器，可以留20G的内存空间给OS Cache