gc的感觉太特别了(gc的感觉太特别了(百度搜索))

（I.概述

如何给出JVM虚拟机的设计参数一直是后续的事情。可能是在网上复制一组参数，可能是公司沿线其他应用的参数。但这样的后续行动可能会给未来留下隐患。给JVM的内存分配内存没有问题，也没有资源。但是，如果分配的内存太小，就会导致频繁的全GC，这提供了一种不是很面向卡的系统。本文分析了JVM虚拟机参数如何与场景连接。

当然，本文更重要的是对参数进行估计，让你对虚拟机中的一些东西有更多的了解。按照最准确的参数设置，用一些工具记录JVM各个区域的变化会更有效。

（2）预准备

系统基于JDK1.8，堆结构如下。

为了促进对商务的理解，本文解释为一个电子商务交易系统。在微服务架构下，主流互联网公司将业务划分为各种服务架构，例如，电子商务系统分为交易微服务、购物车微服务、商品等。或许这种颗粒度会被淡化。底层建筑整合了这些微服务。事实上，一个大容器会装罐头。

（3）通常业务场景中的估计过程

订单对象、优惠券对象、用户对象、交易记录对象等一系列对象，我们可以很容易的估算出这些对象在交易中占用这些对象的空间。估算的方法也很简单，直接进入字节大小的八个基本类型，估算的对象类型以基本类型为基础。只需要一个粗略的值。

例如，每笔交易中的订单对象约为1kb，优惠券对象为2kb，用户对象为4kb，交易记录对象为4kb，可以以列表、数组等形式存在。大约一个事务产生的对象大约是25kb。

日交易量100万系统，交易量主要集中在6小时内，平均每秒40单。还有一种方法可以生成每秒1M大小的物体。在事务结束时，这些生成的对象将被视为垃圾，这意味着每秒将生成1M的垃圾。

假设我们只有一个2核的4G服务器，通过计算分配给堆的内存通常是1.5g，你可以如下计算堆中每个区域的大小：

通过计算可以得出，每隔400秒，400米的伊甸园区域就满了，会进行一次young GC。98%的垃圾将被回收，这意味着大约800万次的垃圾将被转移到幸存者手中。有些对象在几个年轻的GC之后进入上下文，完整的GC出现的频率会很低。400秒的Youngggc虽然略快，但对系统基本没有影响。

（4）特殊业务场景下的估算过程

现在公司计划开展一小时补贴活动。在活动中，订单可能是之前的20次，也就是说一秒钟就会有800个订单，而垃圾在20米每秒的速度下会发生什么？

伊甸园区占用20秒，YoungGCS执行20秒。这时候由于阶次过大，有些界面响应会达到几秒甚至几秒，这些对象经过几个年轻的GC后会逐渐进入老年人。一般来说，一个小时有两次以上。

在这种情况下，我们需要重新考虑我们的机器资源和JVM虚拟机内存。

首先，考虑升级JVM虚拟机内存。由于硬件限制，JVM虚拟机内存的提升首先提升了机器的性能，我们的双核4G升级到了4核8G。分配到405g内存。这个时候伊甸园区域会有1200米的内存。在相同条件下，Youngc将执行1分钟。20秒增加到1分钟，保证慢响应接口对象在不进入老年人的情况下也能在Youngggc。

同时，我们可以将一台机器升级为三台机器。负载均衡后，每台机器订单压力1/3，扬声器时间增加到原来的3倍，界面响应时间加快。基本上三个4核8G的机器就能满足这个事件。

（5）摘要

估计之后，并不代表完全没有问题，还需要准备更多的机器以防意外。实践能给你带来最好的答案。