堆内存相关
Java 虚拟机所管理的内存中最大的一块，Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。
https://www.yuque.com/anner-dhcrb/pafw88/havhc5pzz2haaqsb
堆内存–Xms和Xmx
与性能有关的最常见实践之一是根据应用程序要求初始化堆内存。如果我们需要指定最小和最大堆大小（推荐显示指定大小），以下参数可以帮助你实现：
-Xms<heap size>[unit]
-Xmx<heap size>[unit]
- heap size 表示要初始化内存的具体大小。
- unit 表示要初始化内存的单位。单位为 “g” (GB) 、“m”（MB）、“k”（KB）
Young Generation
根据 Oracle 官方文档 open in new window，在堆总可用内存配置完成之后，第二大影响因素是为 Young Generation 在堆内存所占的比例。默认情况下，YG 的最小大小为 1310 MB，最大大小为_无限制_。
一共有两种指定 新生代内存 (Young Ceneration) 大小的方法：
1. 通过-XX:NewSize和-XX:MaxNewSize指定
-XX:NewSize=<young size>[unit]
-XX:MaxNewSize=<young size>[unit]
举个栗子🌰，如果我们要为 新生代分配 最小 256m 的内存，最大 1024m 的内存我们的参数应该这样来写：
-XX:NewSize=256m
-XX:MaxNewSize=1024m
2. 通过-Xmn<young size>[unit] 指定
举个栗子🌰，如果我们要为 新生代分配 256m 的内存（NewSize 与 MaxNewSize 设为一致），我们的参数应该这样来写：
GC 调优策略中很重要的一条经验总结是这样说的：
将新对象预留在新生代，由于 Full GC 的成本远高于 Minor GC，因此尽可能将对象分配在新生代是明智的做法，实际项目中根据 GC 日志分析新生代空间大小分配是否合理，适当通过 “-Xmn” 命令调节新生代大小，最大限度降低新对象直接进入老年代的情况。
另外，你还可以通过 -XX:NewRatio=<int> 来设置新生代和老年代内存的比值。
比如下面的参数就是设置新生代（包括 Eden 和两个 Survivor 区）与老年代的比值为 1。也就是说：新生代与老年代所占比值为 1：1，新生代占整个堆栈的 1/2。
永久代 — > 元空间
从 Java 8 开始，如果我们没有指定 Metaspace 的大小，随着更多类的创建，虚拟机会耗尽所有可用的系统内存（永久代并不会出现这种情况）。
JDK 1.8 之前永久代还没被彻底移除的时候通常通过下面这些参数来调节方法区大小
-XX:PermSize=N //方法区 (永久代) 初始大小
-XX:MaxPermSize=N //方法区 (永久代) 最大大小,超过这个值将会抛出 OutOfMemoryError 异常:java.lang.OutOfMemoryError: PermGen
相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入方法区后就 “永久存在” 了。
JDK 1.8 的时候，方法区（HotSpot 的永久代）被彻底移除了（JDK1.7 就已经开始了），取而代之是元空间，元空间使用的是本地内存。
下面是一些常用参数：
-XX:MetaspaceSize=N //设置 Metaspace 的初始（和最小大小）
-XX:MaxMetaspaceSize=N //设置 Metaspace 的最大大小，如果不指定大小的话，随着更多类的创建，虚拟机会耗尽所有可用的系统内存。
直接内存
- XX:MaxDirectMemorySize=size用于设置New I/O(java.nio) direct-buffer allocations的最大大小，size的单位可以使用k/K、m/M、g/G；如果没有设置该参数则默认值为0，意味着JVM自己自动给NIO direct-buffer allocations选择最大大小
如果XX:MaxDirectMemorySize不设置就默认和xmx一样的大小
1.8版本最大可以直接内存可以使用参数-XX:MaxDirectMemorySize设置，如不设置，默认值为java heap 的max最大值，-Xmx - from区域的大小（几乎等同xmx）。native heap 达到最大值，不会触发gc，如果释放不了足够的空间，引发宕机的风险
[HotSpot VM] JVM调优的”标准参数”的各种陷阱 - 讨论 - 高级语言虚拟机 - ITeye群组
崩溃记录
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}
- XX:+HeapDumpOnOutOfMemoryError参数表示当JVM发生OOM时，自动生成DUMP文件。
- XX:HeapDumpPath={目录}/java_heapdump.hprof。
如果不指定文件名，默认为：java_
tomcat 下面一般在 bin 下面
2. 垃圾收集相关
2.1. 垃圾回收器
为了提高应用程序的稳定性，选择正确的垃圾收集 open in new window 算法至关重要。
JVM 具有四种类型的 GC 实现：
- 串行垃圾收集器
- 并行垃圾收集器
- CMS 垃圾收集器
- G1 垃圾收集器
可以使用以下参数声明这些实现：
-XX:+UseSerialGC
-XX:+UseParallelGC
-XX:+UseParNewGC
-XX:+UseG1GC
有关_垃圾回收_实施的更多详细信息，请参见此处 open in new window。
2.2.GC 记录
为了严格监控应用程序的运行状况，我们应该始终检查 JVM 的_垃圾回收_性能。最简单的方法是以人类可读的格式记录 GC 活动。
使用以下参数，我们可以记录 GC 活动：
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=< number of log files >
-XX:GCLogFileSize=< file size >[ unit ]
-Xloggc:/path/to/gc.log
java -jar thread-for-java-1.0-SNAPSHOT.jar -Xms100m -Xmx100m -XX:NewSize=80m -XX:+UseSerialGC -XX:+UseGCLogFileRotation -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc-%t.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=2 -XX:GCLogFileSize=1K
实践记录
BI 运行参数记录
-Djava.util.logging.config.file=/data2/BI6_auto/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Xms16G
-Xmx16G
-XX:MaxDirectMemorySize=4g
-Dpolars.connection.timeout=300000
-agentlib:jdwp=transport=dt_socket,address=8278,suspend=n,server=y
-XX:+HeapDumpOnOutOfMemoryError
-XX:PerMethodRecompilationCutoff=-1
-XX:PerBytecodeRecompilationCutoff=-1
-Djdk.tls.ephemeralDHKeySize=2048
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
-Dignore.endorsed.dirs=
-Dcatalina.base=/data2/BI6_auto
-Dcatalina.home=/data2/BI6_auto
-Djava.io.tmpdir=/data2/BI6_auto/temp