本文深入探讨了Java堆内存管理、代空间大小、垃圾回收器选择及其优化策略，包括如何调整堆大小、代空间比例、并发与并行收集器的使用，以及如何应对OutOfMemoryError等问题。
观测性能主要使用gc的统计信息。
-XX:+PrintGC 输出GC信息。
-XX:+PrintGCDetails输出GC详细信息。
-XX:+PrintGCTimeStamps 输出时间戳，和–XX:+PrintGC 或–XX:+PrintGCDetails一起使用。
-Xloggc: gc.log 输出到指定文件。
1 决定堆内存大小。
决定整个堆内存的大小。内存的大小对于Collector的性能影响是最大的。
使用以下参数来决定堆内存的大小。
可以决定堆空间的起始值和最大值，大型程序可以考虑把起始值调大，避免程序启动时频繁GC和内存扩展申请。
以及堆空间中可用内存的比例范围，vm会动态管理堆内存来满足该比例范围。
-XX:MinHeapFreeRatio=n
-XX:MaxHeapFreeRatio=n
-Xms<size> set initial Java heap size Young和Old的起始内存
-Xmx<size> set maximum Java heap size,The maximum heap limit is about 2 GB (2048MB). Young和Old的最大内存
2 决定代空间大小。
Young代空间越大，则minor GC的频率越小。但是，给定堆内存大小，Young代空间大，则major GC频率变大。
如果没有过多的Full GC或者过长的暂停时间问题，给young代尽量大的空间。
Young Generation Guarantee。
对于serial collector，当执行minor GC时，必须保证old代中有可用的空间来处理最坏情况(即eden和survivor空间中的对象都是活对象，需要提升至old空间)，如果不满足，则该minor GC触发major GC。所以对于serial collector，设置eden+survivor的内存不要大过old代内存。
其他collector不做该保证，只有old代无法存储提升对象时才触发major GC。
对于其他collector，由于多线程做minor GC时，考虑到最坏情况，每个线程要在old代内存预留一定空间做对象提升，因此可能导致内存碎片。因此old代内存应该调整的更大一些。
-XX:NewSize=n young代空间下限。
-XX:MaxNewSize=n young代空间上限。
-XX:NewRatio=n young和old代的比例。
-XX:SurvivorRatio=n Eden和单个survivor的比例。
-XX:PermSize=n Permanent起始值。
-XX:MaxPermSize=n Permanent最大值。
3 决定使用Collector收集器
可以考虑是否需要换一个Collector。
Collector选择（四种：单线程、并行、并行Old、并发）
-XX:+UseSerialGC 用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高。但是，也无法使用多处理器的优势，所以此收集器适合单处理器机器。
-XX:+UseParallelGC Parallel 并行收集器,对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用。
-XX:+UseParallelOldGC Parallel compacting（在JAVA SE6.0中新增此选项，对old代也使用并行垃圾回收）
-XX:+UseConcMarkSweepGC Concurrent mark–sweep (CMS) 并发收集器,可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用
设置并行收集器（Parallel和Parallel Compacting Collector）时，还可以设置如下参数.
-XX:ParallelGCThreads=n 并行垃圾回收线程数，此值可以设置与机器处理器数量相等。
-XX:MaxGCPauseMillis=n 指定垃圾回收时的最长暂停时间，如果指定了此值的话，堆大小和垃圾回收相关参数会进行调整以达到指定值。设定此值可能会减少应用的吞吐量-XX:GCTimeRatio=n 吞吐量为垃圾回收时间与非垃圾回收时间的比值，公式为1/（1+n）。例如，-XX:GCTimeRatio=19时，表示5%的时间用于垃圾回收。默认情况为99，即1%的时间用于垃圾回收
设定目标好于明确设定参数值。（？疑问，真的吗？）
为了减小最大暂停时间和footprint，堆大小需要变小。
2个目标有一定的矛盾，因此要视具体应用场景，做平衡。
设置并发收集器时CMS Collector，还可以设置如下参数
-XX:+CMSIncrementalMode 和CMS同时使用。在只有一个处理器的主机上使用并发收集器，设置为incremental mode模式也可获得较短的停顿时间
-XX:+CMSIncrementalPacing 和CMS同时使用。
-XX:ParallelGCThreads=n
-XX:CMSInitiatingOccupancyFraction=n,n为百分比，默认68。因为并发收集在应用运行时进行收集，所以必须保证收集完成之前有足够的内存空间供程序使用，否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=<N>指定还有多少剩余堆时开始执行并发收集
并行收集器的优缺点：
缺点：Cms回收器是唯一不做压缩（compact）的算法、Cms的另外一个缺点在于比需要比其它回收器更大的堆大小
优点：不像其它的回收器，cms回收器不会等到old generation满了才去回收垃圾，而是在old generation满了以前就开始垃圾回收
何时使用cms回收器？
如果你的应用需要更短的垃圾回收暂停时间同时能承担垃圾回收和应用程序分享处理器资源，那么就使用cms回收器吧。如果你的机器有多个处理器，这个算法带来的好处会更多，所以它对web 服务器和交互应用尤其合适。
OutOfMemoryError
可以指定
-XX:+HeapDumpOnOutOfMemoryError
当发生OutOfMemoryError时dump出堆内存。
发生OutOfMemoryError时可以观测该Error的详细信息。
Java heap space：
调整堆大小。
程序中含有大量带有finalize方法的对象。执行finalize方法的线程顶不住了。
PermGen space:
Permanent代内存不够用了。
Requested array size exceeds VM limit。
堆内存不够用。
程序bug，一次分配太多内存。
freeMemory(),totalMemory(),maxMemory()
java.lang.Runtime类中的 freeMemory(), totalMemory(), maxMemory()这几个方法的反映的都是 java这个进程的内存情况，跟操作系统的内存根本没有关系。
maxMemory()这个方法返回的是java虚拟机(这个进程)能构从操作系统那里挖到的最大的内存，以字节为单位，如果在运行java程序的时 候，没有添加-Xmx参数，那么就是jvm默认的可以使用内存大小，client为64M，server为1G。如果添加了-Xmx参数，将以这个参数后面的值为准。
totalMemory()这个方法返回的是java虚拟机现在已经从操作系统那里挖过来的内存大小，也就是java虚拟机这个进程当时所占用的所有内存。如果在运行java的时候没有添加-Xms参数，那么，在java程序运行的过程的，内存总是慢慢的从操作系统那里挖的，基本上是用多少挖多少，直 到挖到maxMemory()为止，所以totalMemory()是慢慢增大的。如果用了-Xms参数，程序在启动的时候就会无条件的从操作系统中挖 -Xms后面定义的内存数，然后在这些内存用的差不多的时候，再去挖。
freeMemory()是什么呢，刚才讲到如果在运行java的时候没有添加-Xms参数，那么，在java程序运行的过程的，内存总是慢慢的从操 作系统那里挖的，基本上是用多少挖多少，但是java虚拟机100％的情况下是会稍微多挖一点的，这些挖过来而又没有用上的内存，实际上就是 freeMemory()，所以freeMemory()的值一般情况下都是很小的，但是如果你在运行java程序的时候使用了-Xms，这个时候因为程 序在启动的时候就会无条件的从操作系统中挖-Xms后面定义的内存数，这个时候，挖过来的内存可能大部分没用上，所以这个时候freeMemory()可能会有些大。
jmap工具的使用
jmap pid 查看共享对象。
jmap -heap pid 查看java进程堆的相关信息。
$ jmap -heap 5695
Attaching to process ID 5695, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 17.0-b16
using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 1342177280 (1280.0MB)
NewSize = 134217728 (128.0MB)
MaxNewSize = 134217728 (128.0MB)
OldSize = 4194304 (4.0MB)
NewRatio = 2
SurvivorRatio = 20000
PermSize = 100663296 (96.0MB)
MaxPermSize = 134217728 (128.0MB)
Heap Usage:
New Generation (Eden + 1 Survivor Space):
capacity = 134152192 (127.9375MB)
used = 34518744 (32.919639587402344MB)
free = 99633448 (95.01786041259766MB)
25.731032408326207% used
Eden Space:
capacity = 134086656 (127.875MB)
used = 34518744 (32.919639587402344MB)
free = 99567912 (94.95536041259766MB)
25.743608670500368% used
From Space:
capacity = 65536 (0.0625MB)
used = 0 (0.0MB)
free = 65536 (0.0625MB)
0.0% used
To Space:
capacity = 65536 (0.0625MB)
used = 0 (0.0MB)
free = 65536 (0.0625MB)
0.0% used
concurrent mark-sweep generation:
capacity = 671088640 (640.0MB)
used = 287118912 (273.81793212890625MB)
free = 383969728 (366.18206787109375MB)
42.7840518951416% used
Perm Generation:
capacity = 100663296 (96.0MB)
used = 41864504 (39.92510223388672MB)
free = 58798792 (56.07489776611328MB)
41.58864816029867% used
jmap –histo pid 查询各种对象占用的内存大小。
$ jmap -histo 5695 | less
num #instances #bytes class name
----------------------------------------------
1: 320290 63305456 [C
2: 1457010 46624320 java.util.concurrent.ConcurrentHashMap$Segment
3: 1502500 36060000 java.util.concurrent.locks.ReentrantLock$NonfairSync
4: 87785 29987632 [I
5: 1457010 23638928 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
6: 285668 15240784 [Ljava.lang.Object;
7: 87239 10680160 <constMethodKlass>
8: 399482 9587568 java.lang.String
9: 16533 7466624 [B
10: 91065 7285072 [Ljava.util.concurrent.ConcurrentHashMap$Segment;
11: 87239 6983288 <methodKlass>
12: 125750 5868720 <symbolKlass>
13: 45409 5449080 java.net.SocksSocketImpl
14: 63574 4936176 [S
15: 45294 4710576 sun.nio.ch.SocketChannelImpl
jmap –permstat pid 查看Class Loader。
jmap –dump:file=filename,format=b pid dump内存到文件。
可以使用MAT工具分析java dump文件。
扫一扫
927
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
