jvm参数调整记录

1. 【推荐】高并发服务器建议调小 TCP 协议的 time_wait 超时时间。
   说明：操作系统默认 240 秒后，才会关闭处于 time_wait 状态的连接，在高并发访问下，服
   务器端会因为处于 time_wait 的连接数太多，可能无法建立新的连接，所以需要在服务器上
   调小此等待值。
   正例：在 linux 服务器上请通过变更/etc/sysctl.conf 文件去修改该缺省值（秒）：
   net.ipv4.tcp_fin_timeout = 30
   例子：在并发情况下服务器会报502异常，此时可以尝试修改该参数去解放连接数
2. 【推荐】调大服务器所支持的最大文件句柄数（File Descriptor，简写为 fd）。
   说明：主流操作系统的设计是将 TCP/UDP 连接采用与文件一样的方式去管理，即一个连接对
   应于一个 fd。主流的 linux 服务器默认所支持最大 fd 数量为 1024，当并发连接数很大时很
   容易因为 fd 不足而出现“open too many files”错误，导致新的连接无法建立。 建议将 linux
   服务器所支持的最大句柄数调高数倍（与服务器的内存数量相关）。
3. 【推荐】给 JVM 设置-XX:+HeapDumpOnOutOfMemoryError 参数，让 JVM 碰到 OOM 场景时输出
   dump 信息。
   说明：OOM 的发生是有概率的，甚至有规律地相隔数月才出现一例，出现时的现场信息对查错
   非常有价值。
4. 【推荐】在线上生产环境，JVM 的 Xms 和 Xmx 设置一样大小的内存容量，避免在 GC 后调整堆
   大小带来的压力。

说明：-server：一定要作为第一个参数，在多个 CPU 时性能佳。还有一种叫-client 的模式，特点是启动速度比较快
-Xmx1024m -Xms1024m -Xmn521m
-xmx1024m 设量JVM最大可用内存为1024M 是堆空间的大小，官方推存是物理内存的1/4,但实际机器是8G，为什么这里只用
了1G？养鱼吗留着

-xms1024m 设置JVM初始内存为1024M 此值可以设置与-Xmx相同，以造免每次垃圾回收完成后JVM重新分配内存
通常-Xms和-xmx在生产环节会设置成完全
一样，原因是如果不设首成一样，-Xms小(比如有人出于好心在不用内存时少用点)
造成的结果是java内存到达一定大小后，觉得内存不够用了而又没到最大值，会做一遍GC把内存放大。当觉得要缩小，也会先
做GC再缩小，最后因为这两个参数设置不一样，造成了多次无用GC。所以线上生产环节不允许这两个值不同

-Xmn521m 设置年轻代大小为521M 整个堆大小=年经代大小＋年老代大小，持久代大小持久代一般国定大小为64m,所以
大年轻代后,将会减小年老代大小 此值对系统性能影响技大, Sun言方推荐配置为整个堆的3/8，但这里用到了1/2 谁道是为了凑成512M，521M也不是整的啊，年经代是GC最频繁的地方，可以在合理情况下设置大些，避免频繁GC

-XX:+PrintGCDetails:启用在每次 GC 时打印洋細消息。默认情况下，此选项处于禁用状态

-XX:+PrintHeapAtGC:每次gc(yonggc.fullgc)都会输出gc前后堆洋情（Eden区域。from区. to区. old区. Metaspace区 Classspace等)

-XX:+PrintGCDate Stamps:输出GC的时间戳（以基准时间的形式）

-XX:+PrintTenuringDistribution -verbose:gc:JVM 在每次新生代GC时，打印出幸存区中对象的年龄分布。

-Xloggc:/applog/omp/wiseoperlservices/logs/gc/api-gateway-gc-%t.log：打印日志位置

-XX:-0mitStackTracelnFastThrow： 如果异常没有栈信息， 需要在JVM中加一个参数-XX-OmitStackTraceinFastThrow强制打印以便于排错。

-Dfastjson.parser.safeMode=true ：处理(fastjson发的漏洞问题