java 虚拟机 xms_JVM虚拟机选项：Xms Xmx PermSize MaxPermSize区别（转）

最新推荐文章于 2023-02-13 12:07:12 发布
最新推荐文章于 2023-02-13 12:07:12 发布
阅读量385 收藏
点赞数
文章标签： java 虚拟机 xms
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42601702/article/details/114902968
版权

java启动参数共分为三类

其一是标准参数( -)，所有的JVM实现都必须实现这些参数的功能，而且向后兼容

其二是非标准参数( -X)，默认jvm实现这些参数的功能，但是并不保证所有jvm实现都满足，且不保证向后兼容

其三是非Stable参数( -XX)，此类参数各个jvm实现会有所不同，将来可能会随时取消，需要慎重使用

java虽然是自动回收内存，但是应用程序，尤其服务器程序最好根据业务情况指明内存分配限制。

否则可能导致应用程序宕掉。

举例说明含义：

-Xms128m

表示JVM Heap(堆内存)最小尺寸128MB，初始分配

-Xmx512m

表示JVM Heap(堆内存)最大允许的尺寸256MB，按需分配。

说明：如果-Xmx不指定或者指定偏小，应用可能会导致java.lang.OutOfMemory错误。

IDEA中配置 -Xms  -Xmx 示例:

5c720d939cabeaf626ede8d506ea5aea.png

PermSize和MaxPermSize指明虚拟机为java永久生成对象(Permanate generation)

如，class对象、方法对象这些可反射(reflective)对象分配内存限制，这些内存不包括在Heap(堆内存)区之中。

-XX:PermSize=64MB 最小尺寸，初始分配

-XX:MaxPermSize=256MB 最大允许分配尺寸，按需分配

过小会导致：java.lang.OutOfMemoryError: PermGen space

MaxPermSize缺省值和-server -client选项相关。

-server选项下默认MaxPermSize为64m

-client选项下默认MaxPermSize为32m

经验：

1、慎用最小限制选项Xms,PermSize已节约系统资源。

=========================================================

近期研究对jvm的内存使用情况进行监控，因此对观察虚拟机的内存使用方法做了一些收集，对jvm的参数设置了解了一下：

几个基本概念：

PermGen space：全称是Permanent Generation space，即永久代。就是说是永久保存的区域,用于存放Class和Meta信息，Class在被Load的时候被放入该区域，GC(Garbage Collection)应该不会对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话，就很可能出现PermGen space错误。

Heap space：存放Instance。Java Heap分为3个区，Young即新生代，Old即老生代和Permanent。Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象。

几个参数设置的意义：

xms/xmx：定义YOUNG+OLD段的总尺寸，

ms为JVM启动时YOUNG+OLD的内存大小；

mx为最大可占用的YOUNG+OLD内存大小。

在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。

NewSize/MaxNewSize：定义YOUNG段的尺寸，

NewSize为JVM启动时YOUNG的内存大小；

MaxNewSize为最大可占用的YOUNG内存大小。

在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。

PermSize/MaxPermSize：定义Perm段的尺寸，PermSize为JVM启动时Perm的内存大小；MaxPermSize为最大可占用的Perm内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。

SurvivorRatio：设置YOUNG代中Survivor空间和Eden空间的比例

申请一块内存的过程：

A. JVM会试图为相关Java对象在Eden中初始化一块内存区域

B. 当Eden空间足够时，内存申请结束。否则到下一步

C. JVM试图释放在Eden中所有不活跃的对象(这属于1或更高级的垃圾回收)；释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区/OLD区

D. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区

E. 当OLD区空间不够时，JVM会在OLD区进行完全的垃圾收集(0级)

F. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”

我们的一种resin服务器的jvm参数设置：

“-Xmx2000M -Xms2000M -Xmn500M -XX:PermSize=250M -XX:MaxPermSize=250M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled-XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=60 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log”

是一种典型的响应时间优先型的配置。

Java中有四种不同的回收算法，对应的启动参数为

–XX:+UseSerialGC

–XX:+UseParallelGC

–XX:+UseParallelOldGC

–XX:+UseConcMarkSweepGC

1. Serial Collector

大部分平台或者强制 java -client 默认会使用这种。

young generation算法 = serial

old generation算法 = serial (mark-sweep-compact)

这种方法的缺点很明显，stop-the-world, 速度慢。服务器应用不推荐使用。

2. Parallel Collector

在linux x64上默认是这种，其他平台要加 java -server 参数才会默认选用这种。

young = parallel，多个thread同时copy

old = mark-sweep-compact = 1

优点：新生代回收更快。因为系统大部分时间做的gc都是新生代的，这样提高了throughput(cpu用于非gc时间)

缺点：当运行在8G/16G server上old generation live object太多时候pause time过长

3. Parallel Compact Collector (ParallelOld)

young = parallel = 2

old = parallel，分成多个独立的单元，如果单元中live object少则回收，多则跳过

优点：old old generation上性能较 parallel 方式有提高

缺点：大部分server系统old generation内存占用会达到60%-80%, 没有那么多理想的单元live object很少方便迅速回收，同时compact方面开销比起parallel并没明显减少。

4. Concurent Mark-Sweep(CMS) Collector

young generation = parallel collector = 2

old = cms

同时不做 compact 操作。

优点：pause time会降低, pause敏感但CPU有空闲的场景需要建议使用策略4.

缺点：cpu占用过多，cpu密集型服务器不适合。另外碎片太多，每个object的存储都要通过链表连续跳n个地方，空间浪费问题也会增大。

内存监控的方法：

1. jmap -heap pid

查看java 堆(heap)使用情况

using thread-local object allocation.

Parallel GC with 4 thread(s)         //GC 方式

Heap Configuration:      //堆内存初始化配置

MinHeapFreeRatio=40    //对应jvm启动参数-XX:MinHeapFreeRatio设置JVM堆最小空闲比率(default 40)

MaxHeapFreeRatio=70 //对应jvm启动参数 -XX:MaxHeapFreeRatio设置JVM堆最大空闲比率(default 70)

MaxHeapSize=512.0MB //对应jvm启动参数-XX:MaxHeapSize=设置JVM堆的最大大小

NewSize = 1.0MB         //对应jvm启动参数-XX:NewSize=设置JVM堆的‘新生代’的默认大小

MaxNewSize =4095MB  //对应jvm启动参数-XX:MaxNewSize=设置JVM堆的‘新生代’的最大大小

OldSize = 4.0MB           //对应jvm启动参数-XX:OldSize=:设置JVM堆的‘老生代’的大小

NewRatio = 8        //对应jvm启动参数-XX:NewRatio=:‘新生代’和‘老生代’的大小比率

SurvivorRatio = 8   //对应jvm启动参数-XX:SurvivorRatio=设置年轻代中Eden区与Survivor区的大小比值

PermSize= 16.0MB      //对应jvm启动参数-XX:PermSize=:设置JVM堆的‘永生代’的初始大小

MaxPermSize=64.0MB //对应jvm启动参数-XX:MaxPermSize=:设置JVM堆的‘永生代’的最大大小

Heap Usage:              //堆内存分步

PS Young Generation

Eden Space:         //Eden区内存分布

capacity = 20381696 (19.4375MB) //Eden区总容量

used    = 20370032 (19.426376342773438MB) //Eden区已使用

free    = 11664 (0.0111236572265625MB) //Eden区剩余容量

99.94277218147106% used //Eden区使用比率

From Space:       //其中一个Survivor区的内存分布

capacity = 8519680 (8.125MB)

used    = 32768 (0.03125MB)

free    = 8486912 (8.09375MB)

0.38461538461538464% used

To Space:           //另一个Survivor区的内存分布

capacity = 9306112 (8.875MB)

used    = 0 (0.0MB)

free    = 9306112 (8.875MB)

0.0% used

PS Old Generation //当前的Old区内存分布

capacity = 366280704 (349.3125MB)

used    = 322179848 (307.25464630126953MB)

free    = 44100856 (42.05785369873047MB)

87.95982001825573% used

PS Perm Generation //当前的 “永生代” 内存分布

capacity = 3

调试参数

打印启动参数

可以查看默认参数

java -XX:+PrintCommandLineFlags-version

打印GC日志

不要用 XX:+UseGCLogFileRotation，这个会丢失旧的日志文件，而且重启会覆盖当前日志文件：

-XX:+PrintGCDetails-XX:+PrintGCDateStamps-Xloggc:/home/GCEASY/gc.log -XX:+UseGCLogFileRotation-XX:NumberOfGCLogFiles=5-XX:GCLogFileSize=20M

应该用下面这个

-XX:+PrintGCDetails-XX:+PrintGCDateStamps-Xloggc:/home/GCEASY/gc-%t.log

打印ClassLoader日志

这个参数会在控制台打印所有类加载/卸载信息

-XX:+TraceClassLoading-XX:+TraceClassUnloading

OOM时Dump内存

-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/crashes/my-heap-dump.hprof

OOM时执行脚本(比如重启)

-XX:OnOutOfMemoryError=/scripts/restart-myapp.sh

打印JIT时间

-XX:-CITime

方法被编译时打印相关信息

-XX:-PrintCompilation

JMX

-Djava.net.preferIPv4Stack=true

-Dcom.sun.management.jmxremote

-Djava.rmi.server.hostname={hostname}

-Dcom.sun.management.jmxremote.port={port}

-Dcom.sun.management.jmxremote.authenticate=false

内存类

JVM设置内存的单位默认是字节(不加单位的情况下)。

也可以在大小后面增加单位，例如：

-Xmn256m

-Xmn262144k

-Xmn268435456

设置初始新生代大小

-XX:NewSize=2G(也可以是2M)

设置最大新生代大小

-XX:MaxNewSize=2G(也可以是2M)

注意：-Xmn优先级大于-XX:NewRatio

设置Eden/Survivor比例

表示两个Survivor和Edgen区的比，8表示两个Survivor:Eden=2:8，即一个Survivor占新生代的1/10。

计算方式为：

SurvivorSize(1) = YoungGenerationSize/ (2+

EdenSize= YoungGenerationSize/ (2+SurvivorRatio) * SurvivorRatio

配置：

-XX:SurvivorRatio=8

8也是默认的比例，不过这个比例在Parallel Scavenge(新生代并行回收器，JDK5以后的默认新生代回收器)回收器下是动态的，运行时会出现Eden/Survivor比例和配置的不同。整编：微信公众号，搜云库技术团队，ID：souyunku

由于与吞吐量关系密切，Parallel Scavenge收集器也经常称为“吞吐量优先”收集器。除上述两个参数之外，Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRatio)、晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略(GC Ergonomics)[插图]。如果读者对于收集器运作原来不太了解，手工优化存在困难的时候，使用Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。只需要把基本的内存数据设置好(如-Xmx设置最大堆)，然后使用MaxGCPauseMillis参数(更关注最大停顿时间)或GCTimeRatio (更关注吞吐量)参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

https://docs.oracle.com/javas...

设置老年代大小

老年代大小无法直接设置，只能通过堆大小+分配比例进行调整

#设置新老一代大小之间的比率。默认值为2。2表示New Size:Old Size=1:2，则新生代占堆大小的1/3，老年代占堆大小的2/3

-XX:NewRatio=2

新生代老年代大小计算方式为：

NewSize= HeapSize/ NewRatio+ 1

OldSize= (HeapSize/ NewRatio+ 1) * NewRatio

设置永久代(PermGen/MetaSpace)大小

#设置分配给永久生成的空间，如果超出该空间，则会触发垃圾回收。此选项在JDK 8中已弃用，并由-XX：MetaspaceSize选项取代。

-XX:PermSize=size

#设置最大永久生成空间大小(以字节为单位)。此选项在JDK 8中已弃用，并由-XX：MaxMetaspaceSize选项取代。

-XX:MaxPermSize=size

#设置分配的Metaspace的大小，Metaspace将在首次超过垃圾收集时触发垃圾收集。垃圾收集的阈值取决于使用的元数据量而增加或减少。默认大小取决于平台。

-XX:MetaspaceSize=size

#设置可以分配给Metaspace的最大本机内存。默认情况下，大小不受限制。应用程序的Metaspace量取决于应用程序本身，其他正在运行的应用程序以及系统上可用的内存量

-XX:MaxMetaspaceSize=size

初始大小和最大值的区别

初始值(比如 -Xms)为JVM启动是向操作系统申请的内存大小( malloc)，最大值(比如 -Xmx)表示，当使用的内存超过初始值后扩容的最大值

PS: JVM配置了多少内存并不是说启动后就会占用多少物理内存，因为操作系统的内存分配是惰性的。对于已申请的内存虽然会分配地址空间，但并不会直接占用物理内存，真正使用的时候才会映射到实际的物理内存。

GC类

5b528ad7464682dbf69cd7f702206259.png

这里说一下PermGen/Metaspace的GC，没有查到官方资料说永久代的固定垃圾回收器，但是在stackoverflow上有人回答到：

所有垃圾回收器都会回收永久代，包括PS/CMS，但并不是每个GC周期都会清理永久代。

这个不用纠结，看GC日志里清理的信息即可。

Serial/Serial Old

最古老的，单线程，独占式，成熟，每次GC会STW，适合单CPU 服务器

Serial是一个新生代收集器，Serial Old是Serial收集器的的老年代版本

新生代和老年代都用串行收集器

-XX:+UseSerialGC

新生代使用ParallerGC，老年代使用Serial Old

-XX:+UseParallelGC

ParNew

和Serial基本没区别，唯一的区别：多线程，多CPU的，停顿时间比Serial少

新生代使用ParNew，老年代使用Serial Old

-XX:+UseParNewGC(在Java8中已弃用，在Java9中已删除)

Parallel Scavenge(ParallerGC)/Parallel Old

关注吞吐量的垃圾收集器，高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。整编：微信公众号，搜云库技术团队，ID：souyunku

所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)，虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

Parallel Scavenge是一个新生代收集器，Parallel Old是Parallel Scavenge收集器的的老年代版本

新生代使用ParallerGC，老年代使用Parallel Old

-XX:+UseParallelGC

#等价于

-XX:+UseParallelOldGC

Concurrent Mark Sweep (CMS)

CMS(Concurrent Mark Sweep)，收集器是一种以获取最短回收停顿时间为目标的收集器，一个老年代垃圾回收器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

新生代使用ParNew，老年代的用CMS

-XX:+UseConcMarkSweepGC

G1

使用G1收集器

-XX:+UseG1GC

垃圾回收器的组合

7a5c57966c821eba61747adfd672d95c.png

下面是一些缺省的写法

c525bd5dab694dbccfe13e2a17f9c3fd.png

JDK7

JAVA_MEM_OPTS=" -server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 "

JAVA_DEBUG_OPTS=" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/home/GCEASY/gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof -XX:OnOutOfMemoryError=/scripts/restart-myapp.sh "

JDK8

JAVA_MEM_OPTS=" -server -Xmx2g -Xms2g -Xmn256m -XX:MetaspaceSize=256m -Xss1024m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 "

JAVA_DEBUG_OPTS=" -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/home/GCEASY/gc-%t.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof -XX:OnOutOfMemoryError=/scripts/restart-myapp.sh "

关于G1，虽然说JDK8中已经支持G1了，但是并不是说一定需要。

G1的重要特点是为用户的应用程序的提供一个低GC延时和大内存GC的解决方案，适用于大内存场景(官方推荐堆6G以上)

如果程序正在使用CMS或ParallelOld垃圾回收器，并且具有一个或多个以下特征，那么则可以考虑升级为G1：

Full GC持续时间太长或太频繁

对象分配率或年轻代升级老年代很频繁

垃圾收集时间或压缩暂停(超过0.5至1秒)时间过长

PS：如果正在使用CMS或ParallelOld收集器，并且程序没有遇到长时间的垃圾收集暂停，那么就不需要升级到G1

作者：空无

来源：http://suo.im/5Y8mTF

weixin_42601702
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
java-JVM.zip_permsiz
09-24
java JVM虚拟机选项： Xms Xmx PermSize MaxPermSize 区别
修改JVM内存
01-15
TOMCAT JVM JAVA 内存 更改JVM 内存大小 TOMCAT JVM 更改 TOM
JVM参数设置详细说明
11-23
JVM参数设置详细说明、JVM 参数设置详细说明 1: heap size a: -Xmx 指定jvm的最大heap大小，如：-Xmx=2g b: -Xms 指定jvm的最小heap大小，如：-Xms=2g，高并发应用，建议和-Xmx一样，防止因为内存收缩/突然增大带来的性能影响。 c: -Xmn 指定jvm中New Generation的大小，如：-Xmn256m。这个参数很影响性能，如果你的程序需要比较多的临时内存，建议设置到512M，如果用的少，尽量降低这个数值，一般来说128/256足以使用了。 d: -XX:PermSize= 指定jvm中Perm Generation的最小值，如：-XX:PermSize=32m。这个参数需要看你的实际情况，可以通过jmap命令看看到底需要多少。 e: -XX:MaxPermSize= 指定Perm Generation的最大值，如：-XX:MaxPermSize=64m f: -Xss 指定线程桟大小，如：-Xss128k，一般来说，webx框架下的应用需要256K。如果你的程序有大规模的递归行为，请考虑设置到512K/1M。这个需要全面的测试才能知道。不过，256K已经很大了。这个参数对性能的影响比较大的。 g: -XX:NewRatio= 指定jvm中Old Generation heap size与New Generation的比例，在使用CMS GC的情况下此参数失效，如：-XX:NewRatio=2 h: -XX:SurvivorRatio= 指定New Generation中Eden Space与一个Survivor Space的heap size比例，-XX:SurvivorRatio=8，那么在总共New Generation为10m的情况下，Eden Space为8m i: -XX:MinHeapFreeRatio= 指定jvm heap在使用率小于n的情况下，heap进行收缩，Xmx==Xms的情况下无效，如：-XX:MinHeapFreeRatio=30 j: -XX:MaxHeapFreeRatio= 指定jvm heap在使用率大于n的情况下，heap 进行扩张，Xmx==Xms的情况下无效，如：-XX:MaxHeapFreeRatio=70 k: -XX:LargePageSizeInBytes= 指定Java heap的分页页面大小， 如：-XX:LargePageSizeInBytes=128m 2: garbage collector a: -XX:+UseParallelGC 指定在New Generation使用parallel collector，并行收集，暂停，app threads，同时启动多个垃圾回收thread，不能和CMS gc一起使用。系统吨吐量优先，但是会有较长长时间的app pause，后台系统任务可以使用此 gc b: -XX:ParallelGCThreads= 指定parallel collection时启动的thread个数，默认是物理processor的个数 c: -XX:+UseParallelOldGC 指定在Old Generation使用parallel collector d: -XX:+UseParNewGC 指定在New Generation使用parallel collector，是UseParallelGC的gc的升级版本，有更好的性能或者优点，可以和CMS gc一起使用 e: -XX:+CMSParallelRemarkEnabled 在使用UseParNewGC的情况下，尽量减少mark的时间 f: -XX:+UseConcMarkSweepGC 指定在Old Generation使用concurrent cmark sweep gc、gc thread和app thread并行（在init-mark和remark时pause app thread）。app pause时间较短，适合交互性强的系统，如web server g: -XX:+UseCMSCompactAtFullCollection 在使用concurrent gc的情况下，防止memory fragmention，对live object进行整理，使memory 碎片减少 h: -XX:CMSInitiatingOccupancyFraction= 指示在old generation 在使用了n%的比例后，启动concurrent collector，默认值是68，如：-XX:CMSInitiatingOccupancyFraction=70 有个bug，在低版本（1.5.09 and early）的jvm上出现， http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089 i: -XX:+UseCMSInitiatingOccupancyOnly 指示只有在old generation在使用了初始化的比例后concurrent collector启动收集 3:others a: -XX:MaxTenuringThreshold= 指定一个object在经历了n次young gc后转移到old generation区，在linux64的java6下默认值是15，此参数对于throughput collector无效，如：-XX:MaxTenuringThreshold=31 b: -XX:+DisableExplicitGC 禁止java程序中的full gc，如System.gc()的调用。最好加上么，防止程序在代码里误用了。对性能造成冲击。 c: -XX:+UseFastAccessorMethods get、set方法转成本地代码 d: -XX:+PrintGCDetails 打应垃圾收集的情况如： [GC 15610.466: [ParNew: 229689K->20221K(235968K), 0.0194460 secs] 1159829K->953935K(2070976K), 0.0196420 secs] e: -XX:+PrintGCTimeStamps 打应垃圾收集的时间情况，如： [Times: user=0.09 sys=0.00, real=0.02 secs] f: -XX:+PrintGCApplicationStoppedTime 打应垃圾收集时，系统的停顿时间，如： Total time for which application threads were stopped: 0.0225920 seconds 4: a web server product sample and process JAVA_OPTS=" -server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 " 最初的时候我们用UseParallelGC和UseParallelOldGC，heap开了3G，NewRatio设成1。这样的配置下young gc发生频率约12、3秒一次，平均每次花费80ms左右，full gc发生的频率极低，每次消耗1s左右。从所有gc消耗系统时间看，系统使用率还是满高的，但是不论是young gc还是old gc，application thread pause的时间比较长，不合适 web 应用。我们也调小New Generation的，但是这样会使full gc时间加长。 后来我们就用CMS gc（-XX:+UseConcMarkSweepGC），当时的总heap还是3g，新生代1.5g后，观察不是很理想，改为jvm heap为2g新生代设置-Xmn1g，在这样的情况下young gc发生的频率变成7、8秒一次，平均每次时间40-50毫秒左右，CMS gc很少发生，每次时间在init-mark和remark（two steps stop all app thread）总共平均花费80-90ms左右。 在这里我们曾经New Generation调大到1400m，总共2g的jvm heap，平均每次ygc花费时间60-70ms左右，CMS gc的init-mark和remark之和平均在50ms左右，这里我们意识到错误的方向，或者说CMS的作用，所以进行了修改。 最后我们调小New Generation为256m，young gc 2、3秒发生一次，平均停顿时间在25毫秒左右，CMS gc的init-mark和remark之和平均在50ms左右，这样使系统比较平滑，经压力测试，这个配置下系统性能是比较高的。 在使用CMS gc的时候他有两种触发gc的方式：gc估算触发和heap占用触发。我们的1.5.0.09 环境下有次old 区heap占用在30%左右，她就频繁gc，个人感觉系统估算触发这种方式不靠谱，还是用 heap 使用比率触发比较稳妥。 这些数据都来自64位测试机，过程中的数据都是我在jboss log找的，当时没有记下来，可能存在一点点偏差，但不会很大，基本过程就是这样。 5: 总结 web server作为交互性要求较高的应用，我们应该使用Parallel+CMS，UseParNewGC这个在jdk6 -server上是默认的new generation gc，新生代不能太大，这样每次pause会短一些。CMS mark-sweep generation可以大一些，可以根据pause time实际情况控制。
java虚拟机内存限制PermSize，MaxPermSize，Xmx，Xms
indieinside的专栏
04-09 8395
PermSize和MaxPermSize指明虚拟机为java永久生成对象（Permanate generation）如，class对象、方法对象这些可反射（reflective）对象分配内存限制， -XX:PermSize=64MB 最小尺寸，初始分配 -XX:MaxPermSize=256MB 最大允许分配尺寸，按需分配 过小会导致：java.lang.OutOfMemoryError:
java8 maxpermsize_JVM虚拟机选项：Xms Xmx PermSize MaxPermSize区别
weixin_39711959的博客
02-13 776
java虽然是自动回收内存，但是应用程序，尤其服务器程序最好根据业务情况指明内存分配限制。否则可能导致应用程序宕掉。举例说明含义：-Xms128m表示JVM Heap(堆内存)最小尺寸128MB，初始分配-Xmx512m表示JVM Heap(堆内存)最大允许的尺寸256MB，按需分配。说明：如果-Xmx不指定或者指定偏小，应用可能会导致java.lang.OutOfMemory错误，此错误来自JV...
java permsize_Java中的“PermSize”是什么？
weixin_34456923的博客
02-15 7647
“永久代”的快速定义：“The permanent generation is used tohold reflective data of the VM itselfsuch as class objects and methodobjects. These reflective objects areallocated directly into the permanentgeneration...
JVM(二) JVM内存配置Xms/Xmx/PermSize/MaxPermSize
热门推荐
lesliehu2158的专栏
11-04 1万+
JVM
Java JVM虚拟机选项Xms/Xmx/PermSize/MaxPermSize（转）
angou6476的博客
09-07 393
通过JVM的这些选项：Xms/Xmx/PermSize/MaxPermSize可以牵扯出很多问题，比如性能调优等。 说明：以下转载没经过实践。 经验实例（参考）： 设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制...
微服务轮子项目（50） -JVM 分析工具详解
阿甘兄
02-08 742
文章目录1. JPS1.1 命令格式1.2. option参数1.3 示例2. jstat2.1. 命令格式2.2 option参数2.3. option 参数总览2.4 option 参数详解2.4.1 -class2.4.2 -compiler2.4.3 -gc2.4.4 -gccapacity2.4.5 -gcutil2.4.6 -gccause2.4.7 -gcnew2.4.8 -gcnewcapacity2.4.9 -gcold2.4.10 -gcoldcapacity2.4.11 -gcp
一文详解jvm之-Xms -Xmx -Xmn -Xss -XX:PermSize -XX:MaxPermSize等参数的设置和优化以及如何选择垃圾回收器
念兮为美
02-13 1万+
一文详解jvm之-Xms -Xmx -Xmn -Xss -XX:PermSize -XX:MaxPermSize等参数的设置和优化以及如何选择垃圾回收器
认识 java JVM虚拟机选项 Xms Xmx PermSize MaxPermSize 区别
12-05
关于内存溢出报错的处理及解决方案： java.lang.OutOfMemoryError: PermGen space java.lang.OutOfMemory 堆内存、非堆内存都描述
JVM调优总结 Xms -Xmx -Xmn -Xss
08-04
JVM调优总结 -Xms -Xmx -Xmn -Xss JVM调优总结 -Xms -Xmx -Xmn -Xss
java maxpermsize 设多少_Xms Xmx PermSize MaxPermSize 区别
weixin_30752995的博客
02-16 7621
1.参数的含义 -vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M -vmargs 说明后面是VM的参数，所以后面的其实都是JVM的参数了 -Xms128m JVM初始分配的堆内存 -Xmx512m JVM最大允许分配的堆内存，按需分配 -XX:PermSize=64M JVM初始分配的非堆内存 -XX:MaxPermSi...
java -Xms -Xmx -XX:PermSize -XX:MaxPermSize
冷月宫主的专栏
09-03 2020
在做java开发时尤其是大型软件开发时经常会遇到内存溢出的问题，比如说OutOfMemoryError等。这是个让开发人员很痛苦、也很纠结的问题，因为我们有时不知道什么样的操作导致了这种问题的发生。所以我们不得不通过不断的优化自己的代码结构，重构了一次又一次。虽然说不断的重构自己的代码对公对私都是一件非常好的事，但是有时我们会发现有些时候不单单是通过重构自身的代码就能够解决这样的问题，因为也可能是
maxpermsize java_关于java：-XX：MaxPermSize带有或不带有-XX：PermSize
weixin_35964787的博客
02-26 1606
我们遇到了Java.lang.OutOfMemoryError：PermGen空间错误，并查看了-Xms和-Xmx参数之外的tomcat JVM参数，我们也指定了-XX:MaxPermSize=128m。 经过一些分析后，我看到偶尔在PermGen空间上发生垃圾收集，从而使其无法完全运行。我的问题是：除了增加-XX:MaxPermSize以外，如果我也指定-XX:PermSize会有什么不同？ 我...
JAVA(-Xms,Xmx,Xmn-XX:newSize,-XX:MaxnewSize,-XX:PermSize,-XX:MaxPermSize)区别
脑壳疼
08-27 1137
1、-Xms：表示java虚拟机堆区内存初始内存分配的大小，通常为操作系统可用内存的1/64大小即可，但仍需按照实际情况进行分配。 2、-Xmx：表示java虚拟机堆区内存可被分配的最大上限，通常为操作系统可用内存的1/4大小。 开发过程中，通常会将-Xms 与-Xmx两个参数的配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源。 1、-XX:newSize：表示新生代初始内存的大小，应该小于-Xms的值； 2、-XX:MaxnewSize：表示新生代可被
java调优
u013131379的博客
04-06 117
1.参数解释 -XX:MetaspaceSize=128m （元空间默认大小） -XX:MaxMetaspaceSize=128m （元空间最大大小） -Xms1024m （堆最大大小） -Xmx1024m （堆默认大小） -Xmn256m （新生代大小） -Xss256k （棧最大深度大小） -XX:SurvivorRatio=8 （新生代分区比例 8:2） -XX:+UseConcMarkSweepGC （指定使用的垃圾收集器，这里使用CMS收集器） -XX:+PrintGCDetails （打印详细
JVM 内存设置大小(Xms Xmx PermSize MaxPermSize 区别)
m0_54853503的博客
08-18 616
其中–launcher.XXMaxPermSize（注意最前面是两个连接线）跟-XX:MaxPermSize参数的含义基本是一样的，我觉得唯一的区别就是前者是eclipse.exe启动的时候设置的参数，JVM最大分配的堆内存由-Xmx指定，默认是物理内存的1/4。通过上面对JVM内存管理的介绍我们已经了解到JVM内存包含两种：堆内存和非堆内存，另外JVM最大内存首先取决于实际的物理内存和操作系统。首先JVM内存限制于实际的最大物理内存，假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。...
node-v5.11.0-x86.msi
最新发布
05-07
Node.js，简称Node，是一个开源且跨平台的JavaScript运行时环境，它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立，旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎，可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型，这使得它非常适合处理大量并发连接，从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外，Node.js使用了模块化的架构，通过npm（Node package manager，Node包管理器）,社区成员可以共享和复用代码，极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展，它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等，因此，开发者可以用JavaScript编写全栈应用程序，这一点大大提高了开发效率和便捷性。 在实践中，许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台，如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能，简化了开发流程，并且能更快地响应市场需求。
jvm -Xms -Xmx -XX:PermSize -XX:MaxPermSize 设置比例
05-13
JVM 中的 -Xms 和 -Xmx 分别用于设置 JVM 的初始堆大小和最大堆大小。而 -XX:PermSize 和 -XX:MaxPermSize 则用于设置永久代（Permanent Generation）的初始大小和最大大小。 这些参数的设置比例应该根据具体的应用...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值