JVM 内存调优 与 实际案例

最新推荐文章于 2025-07-09 18:18:48 发布
最新推荐文章于 2025-07-09 18:18:48 发布
阅读量1.1k 收藏 2
点赞数
分类专栏： Java基础 文章标签： jvm
本文介绍JVM堆内存的分区原理，包括年轻代、年老代和持久代的作用及垃圾回收机制。同时提供了不同应用场景下的JVM参数设置案例。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

堆内存设置

原理

JVM堆内存分为2块：Permanent Space 和 Heap Space。
  • Permanent 即 持久代（Permanent Generation），主要存放的是Java类定义信息，与垃圾收集器要收集的Java对象关系不大。
  • Heap = { Old + NEW = {Eden, from, to} }，Old 即 年老代（Old Generation），New 即 年轻代（Young Generation）。年老代和年轻代的划分对垃圾收集影响比较大。

年轻代

所有新生成的对象首先都是放在年轻代。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代一般分3个区，1个Eden区，2个Survivor区（from 和 to）。

大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当一个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当另一个Survivor区也满了的时候，从前一个Survivor区复制过来的并且此时还存活的对象，将可能被复制到年老代。

2个Survivor区是对称的，没有先后关系，所以同一个Survivor区中可能同时存在从Eden区复制过来对象，和从另一个Survivor区复制过来的对象；而复制到年老区的只有从另一个Survivor区过来的对象。而且，因为需要交换的原因，Survivor区至少有一个是空的。特殊的情况下，根据程序需要，Survivor区是可以配置为多个的（多于2个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。

针对年轻代的垃圾回收即 Young GC。

年老代

在年轻代中经历了N次（可配置）垃圾回收后仍然存活的对象，就会被复制到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

针对年老代的垃圾回收即 Full GC。

持久代

用于存放静态类型数据，如 Java Class, Method 等。持久代对垃圾回收没有显著影响。但是有些应用可能动态生成或调用一些Class，例如 hibernate CGLib 等，在这种时候往往需要设置一个比较大的持久代空间来存放这些运行过程中动态增加的类型。


所以，当一组对象生成时，内存申请过程如下：

  1. JVM会试图为相关Java对象在年轻代的Eden区中初始化一块内存区域。
  2. 当Eden区空间足够时，内存申请结束。否则执行下一步。
  3. JVM试图释放在Eden区中所有不活跃的对象（Young GC）。释放后若Eden空间仍然不足以放入新对象，JVM则试图将部分Eden区中活跃对象放入Survivor区。
  4. Survivor区被用来作为Eden区及年老代的中间交换区域。当年老代空间足够时，Survivor区中存活了一定次数的对象会被移到年老代。
  5. 当年老代空间不够时，JVM会在年老代进行完全的垃圾回收（Full GC）。
  6. Full GC后，若Survivor区及年老代仍然无法存放从Eden区复制过来的对象，则会导致JVM无法在Eden区为新生成的对象申请内存，即出现“Out of Memory”。

OOM（“Out of Memory”）异常一般主要有如下2种原因：

1. 年老代溢出，表现为：java.lang.OutOfMemoryError:Javaheapspace
这是最常见的情况，产生的原因可能是：设置的内存参数Xmx过小或程序的内存泄露及使用不当问题。
例如循环上万次的字符串处理、创建上千万个对象、在一段代码内申请上百M甚至上G的内存。还有的时候虽然不会报内存溢出，却会使系统不间断的垃圾回收，也无法处理其它请求。这种情况下除了检查程序、打印堆内存等方法排查，还可以借助一些内存分析工具，比如MAT就很不错。

2. 持久代溢出，表现为：java.lang.OutOfMemoryError:PermGenspace
通常由于持久代设置过小，动态加载了大量Java类而导致溢出，解决办法唯有将参数 -XX:MaxPermSize 调大（一般256m能满足绝大多数应用程序需求）。将部分Java类放到容器共享区（例如Tomcat share lib）去加载的办法也是一个思路，但前提是容器里部署了多个应用，且这些应用有大量的共享类库。

参数说明

  • -Xmx3550m：设置JVM最大堆内存为3550M。
  • -Xms3550m：设置JVM初始堆内存为3550M。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
  • -Xss128k：设置每个线程的栈大小。JDK5.0以后每个线程栈大小为1M，之前每个线程栈大小为256K。应当根据应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。需要注意的是：当这个值被设置的较大（例如>2MB）时将会在很大程度上降低系统的性能。
  • -Xmn2g：设置年轻代大小为2G。在整个堆内存大小确定的情况下，增大年轻代将会减小年老代，反之亦然。此值关系到JVM垃圾回收，对系统性能影响较大，官方推荐配置为整个堆大小的3/8。
  • -XX:NewSize=1024m：设置年轻代初始值为1024M。
  • -XX:MaxNewSize=1024m：设置年轻代最大值为1024M。
  • -XX:PermSize=256m：设置持久代初始值为256M。
  • -XX:MaxPermSize=256m：设置持久代最大值为256M。
  • -XX:NewRatio=4：设置年轻代（包括1个Eden和2个Survivor区）与年老代的比值。表示年轻代比年老代为1:4。
  • -XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的比值。表示2个Survivor区（JVM堆内存年轻代中默认有2个大小相等的Survivor区）与1个Eden区的比值为2:4，即1个Survivor区占整个年轻代大小的1/6。
  • -XX:MaxTenuringThreshold=7：表示一个对象如果在Survivor区（救助空间）移动了7次还没有被垃圾回收就进入年老代。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代，对于需要大量常驻内存的应用，这样做可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象在年轻代存活时间，增加对象在年轻代被垃圾回收的概率，减少Full GC的频率，这样做可以在某种程度上提高服务稳定性。

疑问解答

-Xmn，-XX:NewSize/-XX:MaxNewSize，-XX:NewRatio 3组参数都可以影响年轻代的大小，混合使用的情况下，优先级是什么？
如下：
  1. 高优先级：-XX:NewSize/-XX:MaxNewSize 
  2. 中优先级：-Xmn（默认等效  -Xmn=-XX:NewSize=-XX:MaxNewSize=?） 
  3. 低优先级：-XX:NewRatio 
推荐使用-Xmn参数，原因是这个参数简洁，相当于一次设定 NewSize/MaxNewSIze，而且两者相等，适用于生产环境。-Xmn 配合 -Xms/-Xmx，即可将堆内存布局完成。
-Xmn参数是在JDK 1.4 开始支持。

垃圾回收器选择

JVM给出了3种选择：串行收集器、并行收集器、并发收集器。串行收集器只适用于小数据量的情况，所以生产环境的选择主要是并行收集器和并发收集器。

默认情况下JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行智能判断。

串行收集器

  • -XX:+UseSerialGC：设置串行收集器。

并行收集器（吞吐量优先）

  • -XX:+UseParallelGC：设置为并行收集器。此配置仅对年轻代有效。即年轻代使用并行收集，而年老代仍使用串行收集。
  • -XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时有多少个线程一起进行垃圾回收。此值建议配置与CPU数目相等。
  • -XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0开始支持对年老代并行收集。
  • -XX:MaxGCPauseMillis=100：设置每次年轻代垃圾回收的最长时间（单位毫秒）。如果无法满足此时间，JVM会自动调整年轻代大小，以满足此时间。
  • -XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动调整年轻代Eden区大小和Survivor区大小的比例，以达成目标系统规定的最低响应时间或者收集频率等指标。此参数建议在使用并行收集器时，一直打开。

并发收集器（响应时间优先）

  • -XX:+UseConcMarkSweepGC：即CMS收集，设置年老代为并发收集。CMS收集是JDK1.4后期版本开始引入的新GC算法。它的主要适合场景是对响应时间的重要性需求大于对吞吐量的需求，能够承受垃圾回收线程和应用线程共享CPU资源，并且应用中存在比较多的长生命周期对象。CMS收集的目标是尽量减少应用的暂停时间，减少Full GC发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代内存。
  • -XX:+UseParNewGC：设置年轻代为并发收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此参数。
  • -XX:CMSFullGCsBeforeCompaction=0：由于并发收集器不对内存空间进行压缩和整理，所以运行一段时间并行收集以后会产生内存碎片，内存使用效率降低。此参数设置运行0次Full GC后对内存空间进行压缩和整理，即每次Full GC后立刻开始压缩和整理内存。
  • -XX:+UseCMSCompactAtFullCollection：打开内存空间的压缩和整理，在Full GC后执行。可能会影响性能，但可以消除内存碎片。
  • -XX:+CMSIncrementalMode：设置为增量收集模式。一般适用于单CPU情况。
  • -XX:CMSInitiatingOccupancyFraction=70：表示年老代内存空间使用到70%时就开始执行CMS收集，以确保年老代有足够的空间接纳来自年轻代的对象，避免Full GC的发生。

其它垃圾回收参数

  • -XX:+ScavengeBeforeFullGC：年轻代GC优于Full GC执行。
  • -XX:-DisableExplicitGC：不响应 System.gc() 代码。
  • -XX:+UseThreadPriorities：启用本地线程优先级API。即使 java.lang.Thread.setPriority() 生效，不启用则无效。
  • -XX:SoftRefLRUPolicyMSPerMB=0：软引用对象在最后一次被访问后能存活0毫秒（JVM默认为1000毫秒）。
  • -XX:TargetSurvivorRatio=90：允许90%的Survivor区被占用（JVM默认为50%）。提高对于Survivor区的使用率。

辅助信息参数设置

  • -XX:-CITime：打印消耗在JIT编译的时间。
  • -XX:ErrorFile=./hs_err_pid.log：保存错误日志或数据到指定文件中。
  • -XX:HeapDumpPath=./java_pid.hprof：指定Dump堆内存时的路径。
  • -XX:-HeapDumpOnOutOfMemoryError：当首次遭遇内存溢出时Dump出此时的堆内存。
  • -XX:OnError=";"：出现致命ERROR后运行自定义命令。
  • -XX:OnOutOfMemoryError=";"：当首次遭遇内存溢出时执行自定义命令。
  • -XX:-PrintClassHistogram：按下 Ctrl+Break 后打印堆内存中类实例的柱状信息，同JDK的 jmap -histo 命令。
  • -XX:-PrintConcurrentLocks：按下 Ctrl+Break 后打印线程栈中并发锁的相关信息，同JDK的 jstack -l 命令。
  • -XX:-PrintCompilation：当一个方法被编译时打印相关信息。
  • -XX:-PrintGC：每次GC时打印相关信息。
  • -XX:-PrintGCDetails：每次GC时打印详细信息。
  • -XX:-PrintGCTimeStamps：打印每次GC的时间戳。
  • -XX:-TraceClassLoading：跟踪类的加载信息。
  • -XX:-TraceClassLoadingPreorder：跟踪被引用到的所有类的加载信息。
  • -XX:-TraceClassResolution：跟踪常量池。
  • -XX:-TraceClassUnloading：跟踪类的卸载信息。

关于参数名称等

  • 标准参数（-），所有JVM都必须支持这些参数的功能，而且向后兼容；例如：
    • -client——设置JVM使用Client模式，特点是启动速度比较快，但运行时性能和内存管理效率不高，通常用于客户端应用程序或开发调试；在32位环境下直接运行Java程序默认启用该模式。
    • -server——设置JVM使Server模式，特点是启动速度比较慢，但运行时性能和内存管理效率很高，适用于生产环境。在具有64位能力的JDK环境下默认启用该模式。
  • 非标准参数（-X），默认JVM实现这些参数的功能，但是并不保证所有JVM实现都满足，且不保证向后兼容；
  • 非稳定参数（-XX），此类参数各个JVM实现会有所不同，将来可能会不被支持，需要慎重使用；

JVM服务参数调优实战

大型网站服务器案例

承受海量访问的动态Web应用

服务器配置：8 CPU, 8G MEM, JDK 1.6.X

参数方案：

-server -Xmx3550m -Xms3550m -Xmn1256m -Xss128k -XX:SurvivorRatio=6 -XX:MaxPermSize=256m -XX:ParallelGCThreads=8 -XX:MaxTenuringThreshold=0 -XX:+UseConcMarkSweepGC

调优说明：

  • -Xmx 与 -Xms 相同以避免JVM反复重新申请内存。-Xmx 的大小约等于系统内存大小的一半，即充分利用系统资源，又给予系统安全运行的空间。
  • -Xmn1256m 设置年轻代大小为1256MB。此值对系统性能影响较大，Sun官方推荐配置年轻代大小为整个堆的3/8。
  • -Xss128k 设置较小的线程栈以支持创建更多的线程，支持海量访问，并提升系统性能。
  • -XX:SurvivorRatio=6 设置年轻代中Eden区与Survivor区的比值。系统默认是8，根据经验设置为6，则2个Survivor区与1个Eden区的比值为2:6，一个Survivor区占整个年轻代的1/8。
  • -XX:ParallelGCThreads=8 配置并行收集器的线程数，即同时8个线程一起进行垃圾回收。此值一般配置为与CPU数目相等。
  • -XX:MaxTenuringThreshold=0 设置垃圾最大年龄（在年轻代的存活次数）。如果设置为0的话，则年轻代对象不经过Survivor区直接进入年老代。对于年老代比较多的应用，可以提高效率；如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率。根据被海量访问的动态Web应用之特点，其内存要么被缓存起来以减少直接访问DB，要么被快速回收以支持高并发海量请求，因此其内存对象在年轻代存活多次意义不大，可以直接进入年老代，根据实际应用效果，在这里设置此值为0。
  • -XX:+UseConcMarkSweepGC 设置年老代为并发收集。CMS（ConcMarkSweepGC）收集的目标是尽量减少应用的暂停时间，减少Full GC发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代内存，适用于应用中存在比较多的长生命周期对象的情况。

内部集成构建服务器案例

高性能数据处理的工具应用

服务器配置：1 CPU, 4G MEM, JDK 1.6.X

参数方案：

-server -XX:PermSize=196m -XX:MaxPermSize=196m -Xmn320m -Xms768m -Xmx1024m

调优说明：

  • -XX:PermSize=196m -XX:MaxPermSize=196m 根据集成构建的特点，大规模的系统编译可能需要加载大量的Java类到内存中，所以预先分配好大量的持久代内存是高效和必要的。
  • -Xmn320m 遵循年轻代大小为整个堆的3/8原则。
  • -Xms768m -Xmx1024m 根据系统大致能够承受的堆内存大小设置即可。
在64位服务器上运行应用程序，构建执行时，用 jmap -heap 11540 命令观察JVM堆内存状况如下：

Attaching to process ID 11540, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 20.12-b01


using thread-local object allocation.
Parallel GC with 4 thread(s)


Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 1073741824 (1024.0MB)
   NewSize          = 335544320 (320.0MB)
   MaxNewSize       = 335544320 (320.0MB)
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 205520896 (196.0MB)
   MaxPermSize      = 205520896 (196.0MB)


Heap Usage:
PS Young Generation
Eden Space:
   capacity = 255852544 (244.0MB)
   used     = 101395504 (96.69828796386719MB)
   free     = 154457040 (147.3017120361328MB)
   39.63044588683081% used
From Space:
   capacity = 34144256 (32.5625MB)
   used     = 33993968 (32.41917419433594MB)
   free     = 150288 (0.1433258056640625MB)
   99.55984397492803% used
To Space:
   capacity = 39845888 (38.0MB)
   used     = 0 (0.0MB)
   free     = 39845888 (38.0MB)
   0.0% used
PS Old Generation
   capacity = 469762048 (448.0MB)
   used     = 44347696 (42.29325866699219MB)
   free     = 425414352 (405.7067413330078MB)
   9.440459523882184% used
PS Perm Generation
   capacity = 205520896 (196.0MB)
   used     = 85169496 (81.22396087646484MB)
   free     = 120351400 (114.77603912353516MB)
   41.440796365543285% used

结果是比较健康的。

JVM性能调优：深入堆内存设置与垃圾回收策略
windowshht的博客
07-02 994
G1垃圾回收器是JDK 7及以后版本中引入的一种新的垃圾回收器，它结合了并行垃圾回收器和CMS垃圾回收器的优点。在垃圾回收过程中，G1垃圾回收器会优先回收包含垃圾最多的区域，从而提高了垃圾回收的效率。CMS垃圾回收器是一种低延迟的垃圾回收器，它主要关注于减少垃圾回收时的停顿时间。通过合理的堆内存设置和选择合适的垃圾回收策略，我们可以提高JVM的性能，确保Java应用程序的高效、稳定运行。由于只有一个线程执行垃圾回收任务，因此它的效率相对较低，但在内存资源有限的情况下，它可能是一个不错的选择。
JVM 性能调优 -- 线上应用 JVM 内存调优【实战】
weixin_42118323的博客
11-22 1792
相信懂与不懂的朋友都会回答不是，确实不是年轻代空间越大越好，老祖宗说过物极必反，JVM 也在堆中进行分带设计，进行分代设计必然是有原因的，我们知道 Minor GC 效率高，那 Minor GC 效率为啥高，这里面有一个根本原因就是年轻代的空间也会相对较小（当然也跟年轻代采用的垃圾回收算法等有关系），试想一下，如果年轻代空间足够大，在进行垃圾回收的时候，单单就标记 GC ROOTS 就需要消耗大量时间，最终在进行垃圾回收的时候同样也要消耗大量时间，如此以来跟 Full GC 又有什么区别呢。
JVM（Java虚拟机）优化大全和案例实战
热门推荐
碧荷故乡_胡奇的专栏
03-06 5万+
堆内存设置原理JVM堆内存分为2块：Permanent Space 和 Heap Space。Permanent 即 持久代（Permanent Generation），主要存放的是Java类定义信息，与垃圾收集器要收集的Java对象关系不大。Heap = { Old + NEW = {Eden, from, to} }，Old 即 年老代（Old Generation），New 即 年轻代（Yo
JVM 调优
最新发布
骑牛小道士
07-09 1230
JVM 调优
IntelliJ IDEA设置JVM运行参数
keeper42的博客
11-09 3134
打开 IDEA 安装目录，看到有一个 bin 目录，其中有两个 vmoptions 文件，需针对不同的JDK进行配置： 32 位：idea.exe.vmoptions 64 位：idea64.exe.vmoptions -Xms512m -Xmx1024m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=225m -XX:+UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB=50 -ea -Dsun.io.u.
java xms xmx 设置_JVM 堆内存设置 -Xmx -Xms
weixin_39552538的博客
02-16 3779
在Tomcat的启动参数里可以设置，如下参数说明：-Xmx Java Heap最大值，默认值为物理内存的1/4，最佳设值应该视物理内存大小及计算机内其他内存开销而定；-Xmx 此设置控制 Java 堆的最大大小。正确调整此参数有助于降低垃圾回收开销，从而缩短服务器响应时间并提高吞吐量。 对于某些应用程序来说，此选项的缺省设置可能会太低，从而导致发生大量小型垃圾回收。缺省值： 512 MB建议...
jvm堆内存的设置
xmh_sxh_1314的博客
04-23 555
Eclipse崩溃，错误提示： MyEclipse has detected that less than 5% of the 64MB of Perm Gen (Non-heap memory) space remains. It is strongly recommended that you exit and restart MyEclipse with new virtual machi...
jvm 调优篇---jvm内存调优的概述篇（含常用命令jinfo等）
健康平安的活着的专栏
08-20 587
输入命令： jinfo -flag NewRatio 17480。
jvm调优 详细 多个案例分析
qq_39989608的博客
02-19 3473
什么时候需要调优
JVM实战 之 JVM参数调优案例
黄老师的博客
10-15 1277
背景 团队线上的(共享基础服务)用户服务user-server和权限服务user-center某段日子内的FullGC过于频繁，且user-center单次FullGC时间过长（1.5s），导致业务高峰期cpu和线程池使用风险压力较大。如图： user-server： user-center： 遇见如此的堆内存图怎么办？ 且看下文。 注：推测+验证的过程很重要。即见识相关的案例，留有思路很重要。 user-server分析过程及实施结果 先晒经验： 在没有显式设置新生代占比时，JVM对于新生代的
JVM第7篇-性能监控 & JVM性能调优案例
qq_43478625的博客
11-25 2185
性能监控一、JVM监控及诊断工具-命令行篇1.1 基础故障处理工具1.1.1 jps: 虚拟机进程状况工具命令格式使用1.1.2 jstat: 虚拟机统计信息监视工具命令格式使用1.1.3 jinfo: Java配置信息工具命令格式使用1.1.4 jmap: Java内存映像分析工具命令格式1.1.5 jstack: Java堆栈跟踪工具命令格式使用二、JVM监控及诊断工具-GUI篇三、JVM运行时参数四、调优概述4.1 生产环境中的问题4.2 调优基本问题为什么要调优?调优的大方向不同阶段的考虑总结4.3
【JVM】【第六章】【JVM 运行时数据区】【堆】【01】堆内存的设置
weixin_43589563的博客
11-26 1019
1、堆的核心概述 1.1 认识堆内存 1.1.1 堆与进程 一个java程序运行起来对应一个JVM进程 一个JVM进程对应一个JVM实例，一个JVM实例中只有一个运行时数据区； 一个运行时数据区只有一个方法区和堆，而一个进程中有多个线程，这就意味着一个进程中的多个线程就要共享方法区和堆；每个线程独享程序计数器、本地方发展、虚拟机栈 1.1.2 对堆的认识 一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。 Java堆区在JVM启动的时候即被创建，JVM启动后其空间大小.
java堆内存设置_java堆内存设置原理
weixin_39592026的博客
02-12 1514
堆内存设置原理JVM堆内存分为2块：Permanent Space 和 Heap Space。Permanent 即 持久代(Permanent Generation)，主要存放的是Java类定义信息，与垃圾收集器要收集的Java对象关系不大。Heap = { Old + NEW = {Eden, from, to} }，Old 即 年老代(Old Generation)，New 即 年轻代(Yo...
JVM内存设置
zsh2050的专栏
12-10 3524
设置JVM内存的参数有四个： -Xmx Java Heap最大值，默认值为物理内存的1/4，最佳设值应该视物理内存大小及计算机内其他内存开销而定，建议设置为可用内存的最大值的80%； -Xms Java Heap初始值，物理内存的1/64，Server端JVM最好将-Xms和-Xmx设为相同值； -Xmn Java Heap Young区大小； -Xss 每个线程的Stac............
JVM之堆内存分配
迎着晨曦，Keep Going
06-05 1401
JVM之堆内存分配
java基础—JVM有哪些常用启动参数可以调整，描述几个？
Daopin Blog
12-06 3455
各主要JVM启动参数的作用如下： -Xms：设置jvm内存的初始大小 -Xmx：设置jvm内存的最大值 -Xmn：设置新域的大小（这个似乎只对jdk1.4来说是有效的，后来就废弃了） -Xss：设置每个线程的堆栈大小(也就是说,在相同物理内存下，减小这个值能生成更多的线程) -XX：NewRatio:设置新域与旧域之比，如-XX：NewRatio=4就表示新域与旧域之比为1：4 -
LRU 是什么？如何实现？ 什么是堆内存？参数如何设置？
weixin_44797327的博客
12-23 1090
堆内存是指由程序代码自由分配的内存，与栈内存作区分。在 Java 中，堆内存主要用于分配对象的存储空间，只要拿到对象引用，所有线程都可以访问堆内存。（1）-Xmx, 指定最大堆内存。如 -Xmx4g. 这只是限制了 Heap 部分的最大值为 4g。这个内存不包括栈内存，也不包括堆外使用的内存。（2）-Xms, 指定堆内存空间的初始大小。如 -Xms4g。而且指定的内存大小，并不是操作系统实际分配的初始值，而是 GC 先规划好，用到才分配。
堆内存参数如何设置？
飞乐鸟的博客
12-02 667
什么是堆内存？参数如何设置
jvm内存调优
03-18
### JVM内存调优方法与参数调整 #### 一、JVM内存结构概述 JVM的内存主要分为以下几个部分：堆内存（Heap Memory）、非堆内存（Non-Heap Memory，主要包括方法区和元空间）、虚拟机栈（Java Stack）、本地方法栈（Native Method Stack）以及程序计数器（Program Counter Register）。这些区域的功能各不相同，在进行调优时需分别考虑其特性[^3]。 #### 二、常见调优目标 JVM调优的主要目的是减少GC频率、缩短停顿时间并提高吞吐量。对于高并发场景下的系统，频繁发生的GC可能导致性能下降甚至服务不可用。因此，合理配置JVM参数至关重要[^2]。 #### 三、具体调优方法及参数说明 ##### 1. 堆内存大小设置 堆内存是JVM中最重要的一部分，用于存储对象实例。可以通过以下参数控制堆内存大小： - `-Xms` 设置初始堆大小。 - `-Xmx` 设置最大堆大小。 通常建议将两者设为相同的值以避免动态扩展带来的开销。针对每秒几十万并发的秒杀系统，可能需要较大的堆内存来应对瞬时流量高峰[^1]。 ```bash java -Xms4g -Xmx4g ... ``` ##### 2. 年轻代与老年代比例调整 年轻代（Young Generation）和老年代（Old Generation/Tenured Generation）的比例会影响Minor GC和Full GC的发生频率。可以使用如下参数调节： - `-XX:NewRatio` 定义新生代与老生代之间的比率，默认值为2表示新生代占整个堆容量的1/3。 - `-XX:SurvivorRatio` 控制Eden区与两个Survivor区之间比例，默认8意味着每个Survivor区占据新生代总大小的1/10。 例如，如果希望更积极地回收短生命周期的对象，则可适当增大新生代占比： ```bash java -XX:NewRatio=1 -XX:SurvivorRatio=6 ... ``` ##### 3. 垃圾收集器的选择 不同的垃圾收集器适用于不同类型的负载模式。以下是几种常见的选择及其适用场景： - **Serial Collector**: 单线程执行，适合小型单核机器上的简单应用程序。 - **Parallel (Throughput) Collector**: 多线程工作方式提升处理能力，推荐给注重吞吐量的应用环境。 - **CMS (Concurrent Mark-Sweep) Collector**: 尽力保持低延迟，适于交互性强的服务端软件；但由于存在“浮动垃圾”，可能会引发promotion failure等问题。 - **G1 Garbage Collector**: 提供更好的预测性和均衡表现，逐渐成为现代大型系统的首选解决方案之一。 启用特定收集器可通过指定相应选项完成，比如开启G1: ```bash java -XX:+UseG1GC ... ``` ##### 4. 其他高级参数 除了上述基础设定外，还有许多细粒度调控手段可供探索，例如： - `-XX:MaxTenuringThreshold`: 设定对象晋升到老年层前允许经历的最大次数。 - `-XX:+PrintGCDetails`, `-XX:+PrintGCDateStamps`: 打印详细的GC过程信息以便分析诊断问题所在。 - `-XX:+HeapDumpOnOutOfMemoryError`: 当发生OOM错误时自动导出heap dump文件辅助排查原因。 #### 四、案例实践 假设某日均百万级交易规模的电商网站面临响应缓慢现象，经初步定位发现是由过多的Full GC引起。此时可以根据实际业务特点尝试以下措施缓解状况： - 加大整体堆尺寸至满足峰值需求； - 调整年轻代所占份额使之能容纳更多临时创建的数据项； - 切换至更适合该类任务特性的垃圾清理机制如G1或ZGC等新型技术路线。 最终效果应通过反复测试验证最佳组合形式，并持续观察生产环境中各项指标变化趋势做出进一步改进决策。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值