简而言之，YDATA服务器应用程序的主要功能是从上游KAFKA接收数据，然后序列化，分类，然后将其发送到KAFKA.DEPLOYED基于Java8。
4G容器存储器已上下测量3.7G，已达到利用率的90％以上。
一个多小时，全GC发生了4次。吞吐量看起来不错。
除了桩内存外，JVM虚拟机还包括虚拟机堆栈，方法区域，直接内存，容器内存等。因此，容器到桩空间的所有内存可能会导致容器存储器使用率超过限制。
它确实监视了超过容器内存限制的情况。
YDATA服务器的所有功能都是消费者数据，序列化等，而无需使用直接内存的逻辑。
可以理解，YDATA服务器的所有功能均在堆内存上执行。
对于堆积空间的分布，新一代的比例为1/3，老年的比例为2/3。但是，在观察垃圾回收的数据时，老年没有垃圾回收，并且记忆力很小。
显然，高频中使用的新一代内存仅仅占堆内存的三分之一，而老年记忆的三分之二的三分之一，但是很长一段时间以来，它已经闲置了，导致内存率太高了。
因此，新一代内存的比例可以适当增加。新一代内存的大小。
在观察垃圾回收的数据时，YDATA服务器有4次全GC。尽管4个完整的GC，但RAN跑是一个很小的价值，但出现的原因值得深入分析。
YDATA服务器的主要逻辑是从Kafka接收数据，序列化等。这些操作很快，操作后应回收相关对象。理论上，YDATA服务器只能导致新一代垃圾回收，并且不会导致新一代的垃圾回收老年人的垃圾回收（平行的垃圾回收，平行的GC在老年时）。
那么是什么原因导致了老年人的废物回收利用呢？
直接原因是老年的对象积累了。（胡说八道）
导致老年人积累的物体的原因是什么？
下图是对象的一般分布过程。可以看出，当S区域中的记忆不足以放下伊甸园的对象时，它将直接放入老年
从以前的垃圾回收情况下，S区域的大小仅为3M，也就是说，如果有大约3M数据在伊甸园地区生存，它将直接进入旧一代，从而导致老年人的积累。
YDATA-Server还提供了一定的REST接口，如果接口返回的数据约为3M，则这些数据可能会直接进入老年。
检查前端页面的界面，发现有一些接口，并且返回的数据相对较大。
重新发布请求并实时监视堆内存。最后，发现记忆的记忆略有略微上升。几个垃圾回收。
为此，可以增加内存堆栈中S区域的大小以使其完全播放。S区域的尺寸比是新一代的2/10，但是平行线将自动调整S面积达到最大系统吞吐量。调整后，S区域变得越来越小。通过禁用自动调整（-XX：-ReadAptivesizepolicy）或使用CMS GC求解，可以禁用效率。
记忆职稳定为1.4g，比以前的降低2G。记忆占用率为35％。
//不再找到场景的屏幕截图，只能描述文本
完整的GC仍然发生了三次，但是这3个完整的GC已经发生在压力测试之前。在压力测试中，从未发送完整的GC。
新一代的垃圾回收经常经常出现，基本上每秒钟将有一次年轻的GC，每次需要130毫秒。也就是说，JVM垃圾回收的吞吐量约为87％，这不是很好。
新一代的垃圾回收经常进行。不可能。数据量太多。因此，它只能增加新一代内存的大小。在老年时，记忆是稳定的，无需增加。
开始垃圾回收后：
可以看出，完整的GC进行了3次，但是老年人占据很小的时间。因此，应在其他地方触发全GC。
除了堆内存外，当方法区域还不够时，还将触发完整的GC。在启动开始时，方法区域的方法太小，并且扩展将扩展。当容量扩大时，全GC发生。
因此，一开始的三个完整GC可能是由于元空间的水位的上升而引起的。
可以通过指定元空间的大小来避免它，例如，Java8之前已经设置了与永久性相关的参数。
因为-XMX2G内存太小，因此频繁地引起了年轻的GC，因此可以正确调整内存并使JVM吞吐量为95秗d降低。吞吐量以换取较小的内存职业。
当平行的旧GC超过老年时，它不可避免地会导致完整的GC。为了避免由于没有到位而引起的一些完整的GC，您应该尝试将老年的记忆保持在较低的价值。通过Majar GC机制进行价值。
与先前的XMX2G设置相比，记忆职的略有增加，但保持60％并且非常稳定。
经过长时间的压力测试，新一代垃圾回收的新一代垃圾回收的数量和时间大大减少。JVM吞吐量已达到95％以上。
1.需要调整的目的，例如吞吐量，内存职业
2.调整的前提是监视。在此调整过程中，JSTAT命令随java，部署在K8s.s.s.s.和Monitor Memory，CPU，网络流量（来自KAFKA的估计数据），JVM垃圾回收等方面的Provence，等等。
3.您需要了解每个Java版本的默认垃圾恢复设备及其原理和特征，并了解相应GC的相关参数
4.您需要对阅读能力和代码有一定的了解。如果您不知道该服务在做什么，那么就无法启动。如果有必要，请阅读项目源代码以了解其实现的相关细节。