JVM参数系列解析

常用参数

-Xmx

-Xmx：设置最大堆内存大小。

-Xms

-Xms：设置初始堆内存大小。

VM options

-Xbootclasspath[]:path

@CallerSensitive注解

-Xbootclasspath:path

完全取代基本核心的Java class 搜索路径.
不常用,否则要重新写所有Java 核心class

-Xbootclasspath/a:path

将指定的资源追加到引导类路径的末尾。
后缀在核心class搜索路径后面.常用!!

-Xbootclasspath/p:path

将指定的资源预置到引导类路径的前面。

CMS系列

-XX:+UseParNewGC

-XX:+UseParNewGC 是一个与Java虚拟机(JVM)垃圾回收策略相关的命令行选项，用于指定使用ParNew垃圾回收器作为年轻代（Young Generation）的垃圾回收算法。ParNew是并行（Parallel）版本的新一代（New Generation）垃圾回收器，它是Serial收集器的并行版本，主要设计目标是在多核处理器环境下通过并行化垃圾回收过程来缩短垃圾回收暂停时间，从而提高应用程序的响应速度。
ParNew垃圾回收器的特点包括：
并行回收：ParNew回收器在垃圾回收过程中利用多核CPU的能力，通过并行执行多个垃圾回收线程来加速垃圾回收过程，减少应用程序的暂停时间。
适合多核处理器：由于ParNew充分利用了多核处理器的并行计算能力，因此在现代多核服务器上表现尤为出色。
与CMS配合使用：ParNew经常与Concurrent Mark Sweep (CMS)回收器一起使用，作为年轻代的垃圾回收器，而CMS则负责老年代（Old Generation）的垃圾回收。这种组合在追求低暂停时间的应用场景中非常受欢迎。
可配置的线程数：用户可以通过 -XX:ParallelGCThreads 参数来指定用于垃圾回收的线程数量，以适应不同硬件环境和应用需求。
然而，ParNew垃圾回收器也有其局限性。例如，虽然它减少了暂停时间，但可能并不总是能最大化吞吐量，因为过多的并行线程可能会导致CPU缓存不一致和上下文切换开销。此外，ParNew回收器在JDK 9之后已被标记为废弃，并在JDK 15中被彻底移除，取而代之的是G1垃圾回收器和其他更先进的回收策略。
因此，对于使用较新版本JDK的应用程序，推荐使用G1垃圾回收器或根据具体需求选择其他适合的垃圾回收策略。G1回收器不仅提供了并行和并发的垃圾回收能力，还支持混合垃圾回收，能够更好地平衡暂停时间和吞吐量，适合各种规模和类型的Java应用程序。

-XX:+UseConcMarkSweepGC

-XX:+UseConcMarkSweepGC 是一个与Java虚拟机(JVM)垃圾回收策略相关的命令行选项，用于指定使用Concurrent Mark Sweep (CMS)垃圾回收器。不过，自JDK 9起，该选项已被重命名为 -XX:+UseConcurrentMarkSweepGC 以符合命名规范，但旧的 -XX:+UseConcMarkSweepGC 仍被保留以保持向后兼容性。
CMS垃圾回收器是专门为减少全局停顿时间设计的，非常适合那些对响应时间有严格要求的应用程序。它通过在应用程序运行的同时执行大部分的标记和清除工作，从而避免了长时间的垃圾回收停顿，使得应用程序能够更加平滑地运行。
CMS回收器的主要特点包括：
并发标记：在应用程序继续运行的同时，CMS回收器会执行对象的标记过程，这减少了全局停顿时间。
并发清除：同样地，CMS回收器在应用程序运行时执行清除过程，但这通常需要一次短暂的停顿，用于处理剩余的引用和完成清除。
低内存碎片：CMS回收器倾向于产生较少的内存碎片，因为它采用的是“标记-清除”算法，而不是“复制”算法。
可预测的停顿时间：CMS回收器试图提供可预测的停顿时间，这对于实时系统非常重要。
然而，CMS回收器也有一些缺点，比如它可能会导致CPU使用率的激增，因为它在应用程序运行时执行大部分的回收工作。此外，CMS回收器不擅长处理高并发的写操作，因为这会增加“remark”阶段的停顿时间。
自JDK 9开始，CMS回收器已被标记为“deprecated”，并最终在JDK 15中被完全移除。取而代之的是G1垃圾回收器，它提供了更好的性能和更稳定的停顿时间。因此，对于现代的Java应用程序，推荐使用G1回收器或其他更先进的垃圾回收策略，而不是CMS回收器。
总结来说，-XX:+UseConcMarkSweepGC / -XX:+UseConcurrentMarkSweepGC 选项用于指定使用CMS垃圾回收器，但鉴于其已被弃用，现代Java应用程序应考虑使用更先进的垃圾回收器。

-XX:+UseCMSInitiatingOccupancyOnly

-XX:+UseCMSInitiatingOccupancyOnly 是一个与Java虚拟机(JVM)的垃圾回收(GC)策略相关的命令行选项，它特定于使用并发标记清除(Concurrent Mark Sweep, CMS)垃圾回收器的场景。
当启用 -XX:+UseCMSInitiatingOccupancyOnly 选项时，JVM 将始终使用由 -XX:CMSInitiatingOccupancyFraction 参数指定的阈值来触发 CMS 垃圾回收过程。这个阈值表示老年代(Old Generation)堆空间的占用百分比，一旦达到或超过这个百分比，CMS GC 就会被触发。
默认情况下，如果没有指定 -XX:+UseCMSInitiatingOccupancyOnly，JVM 可能会基于运行时收集到的性能数据动态调整这个阈值，以优化垃圾回收的时机。但是，当 -XX:+UseCMSInitiatingOccupancyOnly 被设置后，JVM 将不再动态调整阈值，而是严格遵守 -XX:CMSInitiatingOccupancyFraction 的设定值。
例如，如果你设置了 -XX:CMSInitiatingOccupancyFraction=75 和 -XX:+UseCMSInitiatingOccupancyOnly，那么当老年代的使用率达到75%时，CMS GC 将被强制启动，无论当前应用的实际负载如何。
通常，这种设置是在对应用程序的内存使用模式有深入了解的情况下才会使用，以确保垃圾回收发生在最合适的时间点，避免过早或过晚的垃圾回收导致的性能问题。然而，由于现代JVM版本已经弃用了CMS回收器并推荐使用G1或其他更先进的回收器，这个选>项可能在某些JVM版本中不再适用或需要不同的替代方案。

-XX:CMSInitiatingOccupancyFraction

配合-XX:+UseCMSInitiatingOccupancyOnly参数来使用

-XX:+CMSParallelRemarkEnabled

-XX:+CMSParallelRemarkEnabled 是一个与Java虚拟机(JVM)的垃圾回收策略相关的命令行选项，特别针对使用了Concurrent Mark Sweep (CMS)垃圾回收器的环境。此选项用于控制在CMS回收过程中“remark”阶段的并行度。
在CMS垃圾回收器中，“remark”阶段是一个重要的步骤，其主要任务是对存活的对象进行重新标记，以确保在垃圾回收过程中没有遗漏可回收的对象。默认情况下，这个阶段是单线程执行的，这意味着它可能会成为性能瓶颈，尤其是在多核处理器的现代硬件上。
当使用 -XX:+CMSParallelRemarkEnabled 选项时，JVM 将在 “remark” 阶段启用并行处理。这意味着它将利用多个CPU核心同时进行对象的重新标记，从而显著加快这一阶段的速度，减少GC停顿时间，提高应用程序的整体响应性。这对于需要低延迟和高吞吐量的应用场景尤其重要。
然而，值得注意的是，虽然并行remark阶段可以减少GC停顿时间，但它也可能消耗更多的CPU资源，这在CPU资源紧张的环境中可能会影响应用程序的其他部分。因此，是否启用并行remark阶段应该基于具体的应用场景和系统资源情况来决定，可能需要通过性能测试和调优来找到最佳的配置。
此外，随着Java版本的演进，CMS垃圾回收器在某些新版本的JVM中已被弃用或默认不作为首选回收器，取而代之的是G1垃圾回收器等更先进的技术。因此，在使用 -XX:+CMSParallelRemarkEnabled 等与CMS相关的参数时，应确保它们适用于你正在使用的JVM版本。

-XX:+CMSClassUnloadingEnabled

-XX:+CMSClassUnloadingEnabled 是一个与Java虚拟机(JVM)的垃圾回收机制相关的命令行选项，尤其与使用Concurrent Mark Sweep (CMS)垃圾回收器有关。这个选项控制着类卸载的行为，即在CMS回收过程中是否允许卸载不再使用的类。
在Java中，类加载和卸载是类生命周期管理的重要组成部分。类卸载是指当一个类不再被引用并且满足特定条件时，JVM可以从内存中移除该类的过程。这有助于释放不再使用的类所占用的内存，特别是在长时间运行的应用程序中，可以有效防止内存泄漏和提高内存使用效率。
当 -XX:+CMSClassUnloadingEnabled 被启用时，意味着CMS垃圾回收器在执行回收过程时，会尝试卸载那些不再被引用的类。这通常发生在类加载器本身已经成为垃圾（即没有强引用指向它）的情况下。类卸载可以回收由类元数据和常量池等组成的永久代（在Java 8及以前的版本中）或元空间（从Java 9开始）中的空间。
然而，类卸载并不是一个简单的过程，它涉及到复杂的依赖关系检查，以确保不会意外地卸载仍然被应用程序需要的类。因此，尽管类卸载可以带来内存回收的好处，但在某些情况下，它也可能引入额外的性能开销，特别是当类的数量非常大时。此外，类卸载还可能导致应用程序的某些部分需要重新加载类，这可能会影响应用程序的性能和稳定性。
总之，-XX:+CMSClassUnloadingEnabled 允许CMS垃圾回收器在适当的条件下进行类卸载，但是否启用它取决于具体的应用场景和对内存管理的需求。在启用类卸载之前，建议充分评估其对应用程序性能和稳定性的潜在影响。

性能优化相关参数

-XX:+UseCompressedOops

Java SE 6U23 开始，JVM会默认开启压缩指针。

JVM之压缩指针（CompressedOops）

-XX: + DisableExplicitGC

强制禁用手动gc

Java虚拟机System.gc()解析

-XX:+ScavengeBeforeFullGC

-XX:+ScavengeBeforeFullGC 是一个 Java 虚拟机（JVM）的垃圾回收（Garbage Collection, GC）相关参数，主要用于控制在执行 Full GC（即整个堆空间的垃圾回收，包括年轻代和老年代）之前是否先进行一次年轻代的垃圾回收（也称为 Minor GC 或 Scavenge GC）。
当 JVM 需要执行 Full GC 时，如果启用了 -XX:+ScavengeBeforeFullGC 参数，它会在 Full GC 开始前先尝试进行一次年轻代的垃圾回收。这样做的主要目的是尽可能减少 Full GC 的工作量，因为年轻代的垃圾回收通常比 Full GC 快得多，且对系统的影响较小。通过先清理年轻代，可以将一些不再使用的对象从年轻代移除，从而减少 Full GC 需要处理的对象数量，这有助于提高整体的 GC 效率和应用程序的响应时间。
然而，这个参数并非在所有情况下都是有益的。如果年轻代的垃圾回收频率很高或者回收成本较高，频繁地在 Full GC 前进行年轻代回收可能会增加不必要的开销，反而影响应用程序的性能。因此，是否启用 -XX:+ScavengeBeforeFullGC 应该根据具体的应用程序特性和运行时的 GC 行为来决定，通常需要通过监控和测试来确定最佳的配置。
需要注意的是，随着 Java 版本的更新，JVM 默认的垃圾回收器和相关参数的默认行为可能会有所变化。在较新的 Java 版本中，如使用 G1 垃圾回收器时，这个参数可能不再适用或具有不同的效果。因此，在使用任何 GC 相关参数时，都应该参考当前 Java 版本的官方文档。

-XX:SoftRefLRUPolicyMSPerMB

-XX:SoftRefLRUPolicyMSPerMB 是一个与Java虚拟机(JVM)软引用(Soft Reference)和垃圾回收策略相关的命令行参数。它主要用于控制软引用对象的回收策略，尤其是当JVM的堆空间开始变得紧张时，如何决定软引用对象的回收时机。
在Java中，软引用是一种弱化版本的对象引用，它允许对象在内存压力下被垃圾回收器回收，而不是等到内存耗尽时才进行回收。软引用通常用于实现缓存机制，其中缓存项可以在内存不足时被自动清理，而不会导致程序因内存溢出而崩溃。
-XX:SoftRefLRUPolicyMSPerMB 参数允许开发者指定在内存压力下，每兆字节(MB)堆空间中软引用对象可以存活的毫秒数(ms)。这是一个时间窗口的概念，表示在内存紧张的情况下，JVM在尝试回收软引用对象前等待的时间长度。具体来说，这个参数决定了在堆空间使用达到一定阈值后，软引用对象在被回收前可以保持活动状态的时间。
例如，如果设置 -XX:SoftRefLRUPolicyMSPerMB=100，那么每兆字节的堆空间中，软引用对象在内存压力下可以存活大约100毫秒。这意味着，如果堆空间为100MB，则所有软引用对象在内存压力下可以存活大约100 * 100 = 10000毫秒，即10秒左右。
通过调整这个参数，开发者可以控制软引用对象的生存周期，以适应不同应用场景下的内存管理和缓存需求。较低的值会导致软引用对象更快地被回收，适合于内存敏感型应用；而较高的值则允许软引用对象在内存压力下存活更长时间，适用于需要较大缓存容量的场景。
然而，值得注意的是，这个参数的设置需要谨慎，因为它直接影响到软引用对象的生命周期，进而影响到内存的使用效率和应用程序的性能。在实际应用中，可能需要结合具体的业务逻辑和运行时的监控数据来确定最合适的值。

-XX:+ReduceInitialCardMarks

-XX:+ReduceInitialCardMarks 是一个与Java虚拟机(JVM)的垃圾回收(GC)策略相关的命令行选项，特别针对使用了Shenandoah或ZGC等现代垃圾回收器的环境。此选项旨在优化卡表(card table)的初始化过程，以减少GC暂停时间和提高GC效率。
在JVM中，卡表(card table)是一种用于快速检测哪些内存区域可能包含跨代引用的数据结构。在进行垃圾回收时，卡表可以帮助GC算法快速定位到可能需要扫描的对象，从而避免全堆扫描，提高GC效率。然而，卡表的初始化和维护也会带来一定的开销，尤其是在大规模堆中。
当启用 -XX:+ReduceInitialCardMarks 选项时，JVM在启动时会采取一种更为高效的方式来初始化卡表，具体来说，它会尽量减少初始标记的范围，只标记那些确实存在跨代引用的区域。这样做的好处是减少了初始GC的暂停时间，因为不需要对整个堆进行标记，而是只标记那些可能存在引用的区域。
在Shenandoah和ZGC这样的低暂停时间GC中，减少初始卡标记的操作对于进一步降低GC暂停时间尤为重要，因为这些GC器设计的目标之一就是最小化应用程序的暂停时间，以支持对延迟敏感的应用场景。
然而，值得注意的是，-XX:+ReduceInitialCardMarks 的效果和适用性取决于具体的JVM版本和所使用的GC器类型。在某些情况下，如果堆中的跨代引用分布较为均匀，减少初始卡标记可能不会带来显著的性能提升，甚至在某些极端情况下可能会因为额外的检查而略微增加GC的总体开销。因此，是否启用这个选项应该基于具体的应用场景和性能测试结果来决定。
总之，-XX:+ReduceInitialCardMarks 是一个用于优化现代GC器中卡表初始化过程的JVM参数，旨在减少GC暂停时间，提高GC效率，尤其适用于对延迟敏感的应用场景。

-XX:+DoEscapeAnalysis & -XX:+EliminateAllocations

JDK7之后默认开启逃逸分析 .
如果需要关闭逃逸分析 -XX:-DoEscapeAnalysis 即可，不推荐修改该参数。
-XX:+EliminateAllocations 开启标量替换参数 . 该参数的前提是开启了逃逸分析，如果没有开启逃逸分析，仅开启该参数无效。

日志和调试系列参数

-XX:+HeapDumpOnOutOfMemoryError

-XX:+HeapDumpOnOutOfMemoryError 是一个Java虚拟机(JVM)的命令行选项，用于控制在发生 OutOfMemoryError 异常时的行为。当JVM检测到内存不足，无法分配新的对象或数组时，它会抛出 OutOfMemoryError。默认情况下，JVM在抛出此类错误后会终止应用程序，但不会生成任何关于堆内存状态的信息，这可能使得诊断内存泄漏或内存使用不当的问题变得困难。
启用 -XX:+HeapDumpOnOutOfMemoryError 选项后，当JVM遇到 OutOfMemoryError 时，它会自动生成一个堆转储文件(heap dump)，该文件包含了JVM堆内存中所有对象的状态快照。这包括每个对象的类型、大小以及对象之间的引用关系。堆转储文件对于分析内存使用情况、识别内存泄漏源头或理解内存不足的具体原因极为有用。
堆转储文件可以使用多种工具进行分析，例如VisualVM、Eclipse Memory Analyzer (MAT)、IBM HeapAnalyzer等。这些工具能够帮助开发者可视化内存使用情况，查找潜在的内存泄漏，以及优化内存使用。
然而，值得注意的是，生成堆转储文件可能会消耗大量的磁盘空间，尤其是当应用程序的堆内存很大时。此外，生成堆转储文件的过程本身也可能消耗一定的CPU和I/O资源，从而延长 OutOfMemoryError 发生后的应用程序停止响应时间。因此，在生产环境中，通常会结合使用 -XX:HeapDumpPath 参数来指定堆转储文件的保存路径，以避免不必要的磁盘空间占用和性能影响。
总之，-XX:+HeapDumpOnOutOfMemoryError 是一个强大的调试工具，它可以帮助开发者在内存不足的情况下获取关键的内存使用信息，从而更有效地解决内存相关的问题。然而，它的使用需要考虑到可能的资源消耗和性能影响，应在开发和测试环境中充分验证其效果。

-XX:HeapDumpPath

-XX:HeapDumpPath=/var/log/myapp/heapdumps/app_heap_dump_%t.hprof

在这个例子中，%t 是一个占位符，表示JVM会自动添加一个时间戳到文件名中，以便区分不同时间生成的堆转储文件。.hprof 是堆转储文件的常见扩展名，它表明了文件的类型。
需要注意的是，堆转储文件可能非常大，尤其是在大型应用程序中，因此在选择保存路径时，要确保目标位置有足够的磁盘空间。此外，由于生成堆转储文件可能需要一定的时间，这个过程可能会暂时影响应用程序的性能，所以在生产环境中使用时，需要权衡其对应用的影响。