标签：proc 字符 util exp glib xmx objects developer https
1、 简述JVM垃圾回收算法分类
常用的垃圾收集算法
JVM的内存结构包括五大区域：程序计数器、虚拟机栈、本地方法栈、堆区、方法区。其中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生、随线程而灭，因此这几个区域的内存分配和回收都具备确定性，就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。而Java堆区和方法区则不一样、不一样!(怎么不一样说的朗朗上口)，这部分内存的分配和回收是动态的，正是垃圾收集器所需关注的部分
复制算法：
为了解决Mark-Sweep算法的缺陷，Copying算法就被提了出来。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。具体过程如下图所示：
这种算法虽然实现简单，运行高效且不容易产生内存碎片，但是却对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。
很显然，Copying算法的效率跟存活对象的数目多少有很大的关系，如果存活对象很多，那么Copying算法的效率将会大大降低。
复制算法的提出是为了克服句柄的开销和解决内存碎片的问题。它开始时把堆分成 一个对象 面和多个空闲面， 程序从对象面为对象分配空间，当对象满了，基于copying算法的垃圾 收集就从根集合（GC Roots）中扫描活动对象，并将每个 活动对象复制到空闲面(使得活动对象所占的内存之间没有空闲洞)，这样空闲面变成了对象面，原来的对象面变成了空闲面，程序会在新的对象面中分配内存。
标记清除算法：
这是最基础的垃圾回收算法，之所以说它是最基础的是因为它最容易实现，思想也是最简单的。标记-清除算法分为两个阶段：标记阶段和清除阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。具体过程如下图所示：
从图中可以很容易看出标记-清除算法实现起来比较容易，但是有一个比较严重的问题就是容易产生内存碎片，碎片太多可能会导致后续过程中需要为大对象分配空间时无法找到足够的空间而提前触发新的一次垃圾收集动作。
标记-清除算法采用从根集合（GC Roots）进行扫描，对存活的对象进行标记，标记完毕后，再扫描整个空间中未被标记的对象，进行回收，如下图所示。标记-清除算法不需要进行对象的移动，只需对不存活的对象进行处理，在存活对象比较多的情况下极为高效，但由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片。
标记压缩算法
为了解决Copying算法的缺陷，充分利用内存空间，提出了Mark-Compact算法。该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动(美团面试题目，记住是完成标记之后，先不清理，先移动再清理回收对象)，然后清理掉端边界以外的内存(美团问过)
标记-整理算法采用标记-清除算法一样的方式进行对象的标记，但在清除时不同，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题。具体流程见下图：
2、 叙述JVM常用的调优参数
-Xmx：最大JVM可用内存， 例：-Xmx4g
-Xms：最小JVM可用内存， 例：Xms4g
-Xmn：年轻代内存大小，例：-Xmn2560m
-XX:PermSize：永久代内存大小，该值太大会导致fullGC时间过长，太小将增加fullGC频率，例：-XX:PermSize=128m
-Xss：线程栈大小，太大将导致JVM可建的线程数量减少，例：-Xss256k
-XX:+DisableExplicitGC：禁止手动fullGC，如果配置，则System.gc()将无效，比如在为DirectByteBuffer分配空间过程中发现直接内存不足时会显式调用System.gc()
-XX:+UseConcMarkSweepGC：一般PermGen是不会被GC，如果希望PermGen永久代也能被GC，则需要配置该参数
-XX:+CMSParallelRemarkEnabled：GC进行时标记可回收对象时可以并行remark-XX:+UseCMSCompactAtFullCollection 表示在fullGC之后进行压缩，CMS默认不压缩空间
-XX:LargePageSizeInBytes：为java堆内存设置内存页大小，例：-XX:LargePageSizeInBytes=128m
-XX:+UseFastAccessorMethods：对原始类型进行快速优化
-XX:+UseCMSInitiatingOccupancyOnly：关闭预期开始的晋升率的统计
-XX:CMSInitiatingOccupancyFraction：使用cms作为垃圾回收，并设置GC百分比，例：-XX:CMSInitiatingOccupancyFraction=70（使用70％后开始CMS收集）
-XX:+PrintGCDetails：打印GC的详细信息
-XX:+PrintGCDateStamps：打印GC的时间戳
-Xloggc：指定GC文件路径
新生代与老年代的垃圾回收器组合方式
JVM常用的分析工具：
jps：用来查看运行的所有jvm进程；
jinfo：查看进程的运行环境参数，主要是jvm命令行参数；
jstat：对jvm应用程序的资源和性能进行实时监控；
jstack：查看所有线程的运行状态；
jmap：查看jvm占用物理内存的状态；
jhat：+UseParNew
jconsole：
jvisualvm：
jps：Java virutal machine Process Status tool，
jps [-q] [-mlvV] [<hostid>]
-q：静默模式；
-v：显示传递给jvm的命令行参数；
-m：输出传入main方法的参数；
-l：输出main类或jar完全限定名称；
-V：显示通过flag文件传递给jvm的参数；
[<hostid>]：主机id，默认为localhost；
jinfo：输出给定的java进程的所有配置信息；
jinfo [option] <pid>
-flags：to print VM flags
-sysprops：to print Java system properties
-flag <name>：to print the value of the named VM flag
jstack：查看指定的java进程的线程栈的相关信息；
jstack [-l] <pid>
jstack -F [-m] [-l] <pid>
-l：long listings，会显示额外的锁信息，因此，发生死锁时常用此选项；
-m：混合模式，既输出java堆栈信息，也输出C/C++堆栈信息；
-F：当使用“jstack -l PID"无响应，可以使用-F强制输出信息；
jstat：输出指定的java进程的统计信息
jstat -help|-options
jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]
# jstat -options
-class：class loader
-compiler：JIT
-gc：gc
-gccapacity：统计堆中各代的容量
-gccause：
-gcmetacapacity
-gcnew：新生代
-gcnewcapacity
-gcold：老年代
-gcoldcapacity
-gcutil
-printcompilation
[<interval> [<count>]]
interval：时间间隔，单位是毫秒；
count：显示的次数；
-gc：
YGC：新生代的垃圾回收次数；
YGCT：新生代垃圾回收消耗的时长；
FGC：Full GC的次数；
FGCT：Full GC消耗的时长；
GCT：GC消耗的总时长；
jmap：Memory Map, 用于查看堆内存的使用状态；
jhat：Java Heap Analysis Tool
jmap [option] <pid>
查看堆空间的详细信息：
jmap -heap <pid>
查看堆内存中的对象的数目：
jmap -histo[:live] <pid>
live：只统计活动对象；
保存堆内存数据至文件中，而后使用jvisualvm或jhat进行查看：
jmap -dump:<dump-options> <pid>
dump-options:
live dump only live objects; if not specified, all objects in the heap are dumped.
format=b binary format
file=<file> dump heap to <file>
Tomcat的常用优化配置：
(1) 内存空间：
/etc/sysconfig/tomcat, /etc/tomcat/tomcat.conf
JAVA_OPTS="-server -Xms32g -Xmx32g -XX:NewSize= -XX:MaxNewSize= "
-server：服务器模式
-Xms：堆内存初始化大小；
-Xmx：堆内存空间上限；
-XX:NewSize=：新生代空间初始化大小；
-XX:MaxNewSize=：新生代空间最大值；
(2) 线程池设置：
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
常用属性：
maxThreads：最大线程数；
minSpareThreads：最小空闲线程数；
maxSpareThreads：最大空闲线程数；
acceptCount：等待队列的最大长度；
URIEncoding：URI地址编码格式，建议使用UTF-8；
enableLookups：是否启用dns解析，建议禁用；
compression：是否启用传输压缩机制，建议“on";
compressionMinSize：启用压缩传输的数据流最小值，单位是字节；
compressableMimeType：定义启用压缩功能的MIME类型；
text/html, text/xml, text/css, text/javascript
指定垃圾收集器：
-XX:
UseSerialGC：运行于Client模式下，新生代是Serial, 老年代使用SerialOld
UseParNewGC：新生代使用ParNew，老年代使用SerialOld
UseParalellGC：运行于server模式下，新生代使用Serial Scavenge, 老年代使用SerialOld
UseParalellOldGC：新生代使用Paralell Scavenge, 老年代使用Paralell Old
UseConcMarkSweepGC：新生代使用ParNew, 老年代优先使用CMS，备选方式为Serial Old
CMSInitiatingOccupancyFraction：设定老年代空间占用比例达到多少后触发回收操作，默认为68%；
UseCMSCompactAtFullCollection：CMS完成内存回收后是否要进行内存碎片整理；
CMSFullGCsBeforeCompaction：在多少次回收后执行一次内存碎片整理；
ParalellGCThreads：并行GC线程的数量；
定义JVM进程运行特性的参数可大体分为两类：
系统属性：system properties
标志：-X, -XX:
评估标准：
吞吐量优先：-XX:GCTimeRatio=n, 设置垃圾回收的时长占程序运行时长的百分比；
暂停时间优先：-XX:MaxGcPauseRatio=n
显示垃圾回收的统计信息：
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
3、 JAVA进程发生OOM如何调优
OOM，全称“Out Of Memory”，翻译成中文就是“内存用完了”，来源于java.lang.OutOfMemoryError。看下关于的官方说明： Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector. 意思就是说，当JVM因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时，就会抛出这个error（注：非exception，因为这个问题已经严重到不足以被应用处理）。
2）为什么会OOM？
为什么会没有内存了呢？原因不外乎有两点：
1）分配的少了：比如虚拟机本身可使用的内存（一般通过启动时的VM参数指定）太少。
2）应用用的太多，并且用完没释放，浪费了。此时就会造成内存泄露或者内存溢出。
内存泄露：申请使用完的内存没有释放，导致虚拟机不能再次使用该内存，此时这段内存就泄露了，因为申请者不用了，而又不能被虚拟机分配给别人用。
内存溢出：申请的内存超出了JVM能提供的内存大小，此时称之为溢出。
在之前没有垃圾自动回收的日子里，比如C语言和C++语言，我们必须亲自负责内存的申请与释放操作，如果申请了内存，用完后又忘记了释放，比如C++中的new了但是没有delete，那么就可能造成内存泄露。偶尔的内存泄露可能不会造成问题，而大量的内存泄露可能会导致内存溢出。
而在Java语言中，由于存在了垃圾自动回收机制，所以，我们一般不用去主动释放不用的对象所占的内存，也就是理论上来说，是不会存在“内存泄露”的。但是，如果编码不当，比如，将某个对象的引用放到了全局的Map中，虽然方法结束了，但是由于垃圾回收器会根据对象的引用情况来回收内存，导致该对象不能被及时的回收。如果该种情况出现次数多了，就会导致内存溢出，比如系统中经常使用的缓存机制。Java中的内存泄露，不同于C++中的忘了delete，往往是逻辑上的原因泄露。
3）OOM的类型
JVM内存模型：
按照JVM规范，JAVA虚拟机在运行时会管理以下的内存区域：
程序计数器：当前线程执行的字节码的行号指示器，线程私有
JAVA虚拟机栈：Java方法执行的内存模型，每个Java方法的执行对应着一个栈帧的进栈和出栈的操作。
本地方法栈：类似“ JAVA虚拟机栈 ”，但是为native方法的运行提供内存环境。
JAVA堆：对象内存分配的地方，内存垃圾回收的主要区域，所有线程共享。可分为新生代，老生代。
方法区：用于存储已经被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。Hotspot中的“永久代”。
运行时常量池：方法区的一部分，存储常量信息，如各种字面量、符号引用等。
直接内存：并不是JVM运行时数据区的一部分， 可直接访问的内存， 比如NIO会用到这部分。
按照JVM规范，除了程序计数器不会抛出OOM外，其他各个内存区域都可能会抛出OOM。
最常见的OOM情况有以下三种：
java.lang.OutOfMemoryError: Java heap space ------>java堆内存溢出，此种情况最常见，一般由于内存泄露或者堆的大小设置不当引起。对于内存泄露，需要通过内存监控软件查找程序中的泄露代码，而堆大小可以通过虚拟机参数-Xms,-Xmx等修改。
java.lang.OutOfMemoryError: PermGen space ------>java永久代溢出，即方法区溢出了，一般出现于大量Class或者jsp页面，或者采用cglib等反射机制的情况，因为上述情况会产生大量的Class信息存储于方法区。此种情况可以通过更改方法区的大小来解决，使用类似-XX:PermSize=64m -XX:MaxPermSize=256m的形式修改。另外，过多的常量尤其是字符串也会导致方法区溢出。
java.lang.StackOverflowError ------> 不会抛OOM error，但也是比较常见的Java内存溢出。JAVA虚拟机栈溢出，一般是由于程序中存在死循环或者深度递归调用造成的，栈大小设置太小也会出现此种溢出。可以通过虚拟机参数-Xss来设置栈的大小。
4）OOM分析--heapdump
要dump堆的内存镜像，可以采用如下两种方式：
设置JVM参数-XX:+HeapDumpOnOutOfMemoryError，设定当发生OOM时自动dump出堆信息。不过该方法需要JDK5以上版本。
使用JDK自带的jmap命令。"jmap -dump:format=b,file=heap.bin <pid>" 其中pid可以通过jps获取。
dump堆内存信息后，需要对dump出的文件进行分析，从而找到OOM的原因。常用的工具有：
mat: eclipse memory analyzer, 基于eclipse RCP的内存分析工具。详细信息参见：http://www.eclipse.org/mat/，推荐使用。
jhat：JDK自带的java heap analyze tool，可以将堆中的对象以html的形式显示出来，包括对象的数量，大小等等，并支持对象查询语言OQL，分析相关的应用后，可以通过http://localhost:7000来访问分析结果。不推荐使用，因为在实际的排查过程中，一般是先在生产环境 dump出文件来，然后拉到自己的开发机器上分析，所以，不如采用高级的分析工具比如前面的mat来的高效。
这个链接：http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html中提供了一个采用mat分析的例子 。
注意：因为JVM规范没有对dump出的文件的格式进行定义，所以不同的虚拟机产生的dump文件并不是一样的。在分析时，需要针对不同的虚拟机的输出采用不同的分析工具（当然，有的工具可以兼容多个虚拟机的格式）。IBM HeapAnalyzer也是分析heap的一个常用的工具。
5）小结
涉及到的虚拟机的技术或者工具，往往需要考虑到虚拟机规范以及不同的虚拟机实现。尤其是针对虚拟机调优时，往往需要针对虚拟机在某些方面的实现策略来考虑，比如，不同的虚拟机的垃圾回收算法是不一样的，而这直接影响了虚拟机某些参数的设置，以达到虚拟机的最佳性能。
而针对JVM运行时的分析与诊断，则需要掌握分析基本方法，针对具体情况，运用虚拟机的原理，具体分析。一句话，水很深啊
标签：proc 字符 util exp glib xmx objects developer https
原文地址：https://www.cnblogs.com/woaiyitiaochai/p/11757984.html
