我的新课
《C2C 电商系统微服务架构120天实战训练营》
在公众号
儒猿技术窝
上线了，感兴趣的同学，可以长按扫描下方二维码了解课程详情：
课程大纲请参见文末
“
这篇文章，给大家聊一个生产环境的实践经验：线上系统部署的时候，
JVM堆内存大小是越大越好吗
？
先说明白一个前提，本文主要讨论的是Kafka和Elasticsearch两种分布式系统的线上部署情况，不是普通的Java应用系统。
先说明一点，不管是我们自己开发的Java应用系统，还是一些中间件系统，在实现的时候都需要选择是否基于自己Java进程的内存来处理数据。
大家应该都知道，Java、Scala等编程语言底层依赖的都是JVM，那么只要是使用JVM，就可以考虑在JVM进程的内存中来放置大量的数据。
还是给大家举个例子，大家应该还记得之前聊过消息中间件系统。
比如说系统A可以给系统B发送一条消息，那么中间需要依赖一个消息中间件，系统A要先把消息发送到消息中间件，然后系统B从这个消息中间件消费到这条消息。
大家看下面的示意图。
大家应该都知道，一条消息发送到消息中间件之后，有一种处理方式，就是把这条数据先缓冲在自己的JVM内存里。
然后过一段时间之后，再从自己的内存刷新到磁盘上去，这样可以持久化保存这条消息，如下图。
如果用类似上述的方式，依赖Java系统自身内存处理数据，比如说设计一个内存缓冲区，来缓冲住高并发写入的大量消息，那么是有其缺陷的。
最大的缺陷，其实就是JVM的GC问题，这个GC就是垃圾回收，这里简单说一下他是怎么回事。
大家可以想一下，如果一个Java进程里老是塞入很多的数据，这些数据都是用来缓冲在内存里的，但是过一会儿这些数据都会写入磁盘。
那么写入磁盘之后，这些数据还需要继续放在内存里吗？
明显是不需要的了，此时就会依托JVM垃圾回收机制，把内存里那些不需要的数据给回收掉，释放掉那些内存空间腾出来。
但是JVM垃圾回收的时候，有一种情况叫做stop the world，就是他会停止你的工作线程，就专门让他进行垃圾回收。
这个时候，他在垃圾回收的时候，有可能你的这个中间件系统就运行不了了。
比如你发送请求给他，他可能都没法响应给你，因为他的接收请求的工作线程都停了，现在人家后台的垃圾回收线程正在回收垃圾对象。
大家看下图。
虽然说现在JVM的垃圾回收器一直在不断的演进和发展，从CMS到G1，尽可能的在降低垃圾回收的时候的影响，减少工作线程的停顿。
但是你要是完全依赖JVM内存来管理大量的数据，那在垃圾回收的时候，或多或少总是有影响的。
所以特别是对于一些大数据系统，中间件系统，这个JVM的GC（Garbage Collector，垃圾回收）问题，真是最头疼的一个问题。
所以类似Kafka、Elasticsearch等分布式中间件系统，虽然也是基于JVM运行的，但是他们都选择了依赖OS Cache来管理大量的数据。
也就是说，是操作系统管理的内存缓冲，而不是依赖JVM自身内存来管理大量的数据。
具体来说，比如说Kafka吧，如果你写一条数据到Kafka，他实际上会直接写入磁盘文件。
但是磁盘文件在写入之前其实会进入os cache，也就是操作系统管理的内存空间，然后过一段时间，操作系统自己会选择把他的os cache的数据刷入磁盘。
然后后续在消费数据的时候，其实也会优先从os cache（内存缓冲）里来读取数据。
相当于写数据和读数据都是依托于os cache来进行的，完全依托操作系统级别的内存区域来进行，读写性能都很高。
此外，还有另外一个好处，就是不要依托自身JVM来缓冲大量的数据，这样可以避免复杂而且耗时的JVM垃圾回收操作。
大家看下面的图，其实就是一个典型的Kafka的运行流程。
然后比如Elasticsearch，他作为一个现在最流行的分布式搜索系统，也是采用类类似的机制。
大量的依赖os cache来缓冲大量的数据，然后在进行搜索和查询的时候，也可以优先从os cache（内存区域）中读取数据，这样就可以保证非常高的读写性能。
依赖os cache的系统JVM内存越大越好？
所以现在就可以进入我们的主题了，那么比如就以上述说的kafka、elasticsearch等系统而言，在线上生产环境部署的时候，你知道他们是大量依赖于os cache来缓冲大量数据的。
那么，给他们分配JVM堆内存大小的时候是越大越好吗？
明显不是的，假如说你有一台机器，有32GB的内存，现在你如果在搞不清楚状况的情况下，要是傻傻的认为还是给JVM分配越大内存越好，此时比如给了16G的堆内存空间给JVM，那么os cache剩下的内存，可能就不到10GB了，因为本身其他的程序还要占用几个GB的内存。
那如果是这样的话，就会导致你在写入磁盘的时候，os cache能容纳的数据量很有限。
比如说一共有20G的数据要写入磁盘，现在就只有10GB的数据可以放在os cache里，然后另外10GB的数据就只能放在磁盘上。
此时在读取数据的时候，那么起码有一半的读取请求，必须从磁盘上去读了，没法从os cache里读，谁让你os cache里就只能放的下10G的一半大小的数据啊，另外一半都在磁盘里，这也是没办法的
，如下图。
那此时你有一半的请求都是从磁盘上在读取数据，必然会导致性能很差。
