一、堆内存大小和年轻代占比
1、这个是个影响最大的配置，在机器配置允许的情况下，堆内存给的越大越好；另外，堆内存的最大和最小值一定要设置成一样的，因为jvm堆内存扩容的时候会触发full gc，元空间也一样，最大内存和最小内存值设置成一样的
2、年轻代的占比一般来说是大一些比较好，因为这样会减少young gc的次数（ZGC之前的回收器young gc都是STW的）
二、回收器应该怎么去选择
一般来说，现在的后端服务有两种，一种是对延迟不是很敏感的，比如多数的数据处理、分析类型的应用（多为OLAP型），这种应用的GC回收器，一般是选择### Parallel 和 Parallel Old，这哥两都是以吞吐量为优先的垃圾回收器。另外一种应用是对延迟比较敏感的，一般应该选用G1。
《深入理解java虚拟机》这本书上说过，在内存比较小的情况下，应该选用CMS而不是G1，但是经过作者在各种场景和各种小内存情况下测试，G1都比CMS好了太多，所以作者从实际的角度出发，推荐在追求低延迟的场景下使用G1。
三、高并发场景（有难度的一个场景）
需要注意的是高并发的场景，这时候应该是去选择低停顿而不是高吞吐量的回收器，因为ps回收器的这两个哥们，在young gc和old gc的时候都是stw的，而G1的mixed gc的一些回收阶段最少还是能够和用户线程并发去执行的，这样会减少stw的时间。在高并发之下，一定要想办法去减少stw，因为在高并发的时候的由于gc而导致的stw，这时候java进程中只有gc线程在活动，而gc的线程优先级比较低，这样的话，操作系统资源就更容易被分配去处理并发请求（注意线程优先级不仅仅是java的概念），导致gc线程被分配到的时间变少，然后stw时间进一步增加，然后导致请求进一步堆积，进而导致gc效率进一步降低和频率进一步升高的恶性循环。
四、其他简单一些规范
1、栈大小
jvm默认是1M，但是其实大多数情况下256K足矣，这样可以减少StackOverFlow的概率
2、堆内存/元空间最大最小值设置为一样
这是因为不论是堆内存还是元空间，在动态扩容的时候，都会出发full gc，这个原理有点类似于数组扩容。
3、OOM发生的时候dump日志
这点就不必解释太多了。
4、full gc前后dump
这一点要谨慎，因为dump其实是个很消耗资源的操作，仅仅用在测试环境，生产环境最好不要用。
5、线上严禁开jvm 的远程debug
这也是个低级错误。
6、禁止显式调用System.gc()
同上，也是低级错误，gc不要人为调用。
7、不要试图通过参数将停顿时间控制的很短
这个是由于jvm的不可能三角所导致的，停顿时间非常短的时候，对应的gc的频率就会增加，进而导致吞吐量降低。
