快学Big Data -- Tomcat（九）

Tomcat 总结

概述

    Tomcat 是常用的web开发服务器之一，在并发时有一定的局限性，一般的大型的网站采用NGINX与tomcat结合使用从而减少单个机器压力的问题。

 

1-1）、Tomcatxi线程池的使用

server.xml优化

进入apache-tomcat-7.0.55/conf路径，修改server.xml文件。

 

注释如下的原始配置

 

<Connector port="8080" protocol="HTTP/1.1"

               connectionTimeout="20000"

               redirectPort="8443" />

 

增加如下配置，如原配置文件有，则取消注释进行修改即可。

 

<!--共享执行器，能定义一个或多个线程池-->

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"

        maxThreads="6000" minSpareThreads="100" maxIdleTime="60000" maxSpareThreads="500"/>

 

最大线程500（一般服务器足以），最小空闲线程数20，线程最大空闲时间60秒。

 

<!--能使用线程池的连接器-->

<Connector executor="tomcatThreadPool"

               port="8080" protocol="HTTP/1.1"

               connectionTimeout="60000"

               keepAliveTimeout="15000"

               redirectPort="8443"

               maxHttpHeaderSize="8192"

               URIEncoding="UTF-8"

               enableLookups="false"

               acceptCount="500"

               disableUploadTimeout="true"/>

   

参数说明：

connectionTimeout - 网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒

keepAliveTimeout - 长连接最大保持时间（毫秒）。此处为15秒

maxKeepAliveRequests - 最大长连接个数（1表示禁用，-1表示不限制个数，默认100个。一般设置在100~200之间）

maxHttpHeaderSize - http请求头信息的最大程度，超过此长度的部分不予处理，一般8K。

URIEncoding - 指定Tomcat容器的URL编码格式。

acceptCount - 指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理，默认为10个。

disableUploadTimeout - 上传时是否使用超时机制。

enableLookups - 是否反查域名，取值为：true或false，为了提高处理能力，应设置为false。

bufferSize - 定义连接器输入流缓存大小，默认2048bytes。

maxSpareThreads - 做多空闲连接数，一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程 。

maxThreads - 最多同时处理的连接数，Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。

minSpareThreads - 最小空闲线程数，Tomcat初始化时创建的线程数。

启动内存优化

catalina.sh 优化

 

# OS specific support.  $var _must_ be set to either true or false.

 

JAVA_OPTS="-XX:PermSize=64M -XX:MaxPermSize=128m -Xms512m -Xmx1024m -Duser.timezone=Asia/Shanghai"

 

-vmargs 说明后面是VM的参数，所以后面的其实都是JVM的参数了

-Xms128m JVM初始分配的堆内存

-Xmx512m JVM最大允许分配的堆内存，按需分配

-XX:PermSize=64M JVM初始分配的非堆内存

-XX:MaxPermSize=128M JVM最大允许分配的非堆内存，按需分配

-Duser.timezone

 

-Xms/-Xmx 也就是新生代与老年代

 

1-2）、启动方式

[root@skycloud3 bin]# ./startup.sh 或

[root@skycloud3 bin]# ./startup.sh ;tail -f ../logs/catalina.out

 

JVM 总结

概述

   需要监控服务器上的JAVA或者其他的进程的执行情况，因不能在服务器上直接操作因而需要软件来链接进行监控，并进行优化。下面简单的介绍一下过程。

 

环境准备

public class TestDeadThread implements Runnable {

int a, b;

 

public TestDeadThread(int a, int b) {

this.a = a;

this.b = b;

}

 

@Override

public void run() {

synchronized (Integer.valueOf(a)) {

synchronized (Integer.valueOf(b)) {

System.out.println(a + b);

}

}

}

 

public static void main(String[] args) throws InterruptedException {

Thread.sleep(3000);

for (int i = 0; i < 100; i++) {

new Thread(new TestDeadThread(1, 2)).start();

new Thread(new TestDeadThread(2, 1)).start();

}

}

}

 

工具：

1- 1 )、Jconsole   

   

 

 

 

 

 

 

1-2 ) 、jvisualvm  

 

 

 

 

 

 

 

 

可以看到详细的信息：

 

 

在这里查看详细线程的信息

 

1-3）、命令行查看线程的运行情况

[root@hadoop1 testJava]# jps

17319 Test

A）、Jstack查看堆栈的运行情况

[root@hadoop1 ~]# jstack -l 17319

2016-11-30 06:08:57

Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.76-b04 mixed mode):

 

"Attach Listener" daemon prio=10 tid=0x00007f08c8001000 nid=0x43f0 waiting on condition [0x0000000000000000]

   java.lang.Thread.State: RUNNABLE

 

   Locked ownable synchronizers:

- None

 

"Service Thread" daemon prio=10 tid=0x00007f08e408d000 nid=0x43af runnable [0x0000000000000000]

   java.lang.Thread.State: RUNNABLE

 

   Locked ownable synchronizers:

- None

 

*******************************

 

B）、Jstat 的使用

1-1）、格式

jstat -options port

1-2）、参数

class (类加载器)

compiler (JIT)

gc (GC堆状态)

gccapacity (各区大小)

gccause (最近一次GC统计和原因)

gcnew (新区统计)

gcnewcapacity (新区大小)

gcold (老区统计)

gcoldcapacity (老区大小)

gcpermcapacity (永久区大小)

gcutil (GC统计汇总)

printcompilation (HotSpot编译统计)

 

1-3）、实例

[root@hadoop1 ~]# jstat -gc 17319  1000  5

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT   

960.0  960.0   0.0    0.0    8000.0   816.4    19904.0      0.0     21248.0 2429.6      0    0.000   0      0.000    0.000

960.0  960.0   0.0    0.0    8000.0   816.4    19904.0      0.0     21248.0 2429.6      0    0.000   0      0.000    0.000

960.0  960.0   0.0    0.0    8000.0   816.4    19904.0      0.0     21248.0 2429.6      0    0.000   0      0.000    0.000

960.0  960.0   0.0    0.0    8000.0   816.4    19904.0      0.0     21248.0 2429.6      0    0.000   0      0.000    0.000

960.0  960.0   0.0    0.0    8000.0   816.4    19904.0      0.0     21248.0 2429.6      0    0.000   0      0.000    0.000

 

 

17319 ：当前运行的PID

1000 ：多少毫秒打印一次

5 ： 打印多少次

 

 

space 0 区已使用空间的百分比

S1C：S1当前容量的大小

S0U：S0已经使用的大小

S1U：S1已经使用的大小

EC：Eden space当前容量的大小

EU：Eden space已经使用的大小

OC：Old space当前容量的大小

OU：Perm space已经使用的大小

P   — Perm space 区已使用空间的百分比

YGC — 从应用程序启动到采样时发生 Young GC 的次数

YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)

FGC — 从应用程序启动到采样时发生 Full GC 的次数

FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)

GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)，它的值等于YGC+FGC

 

 

查看各区域的大小gccapacity

[root@hadoop1 ~]# jstat  -gccapacity  17319  1000  5

 NGCMN    NGCMX     NGC     S0C   S1C       EC      OGCMN      OGCMX       OGC         OC      PGCMN    PGCMX     PGC       PC     YGC    FGC

  9920.0 159040.0   9920.0  960.0  960.0   8000.0    19904.0   318144.0    19904.0    19904.0  21248.0  83968.0  21248.0  21248.0      0     0

  9920.0 159040.0   9920.0  960.0  960.0   8000.0    19904.0   318144.0    19904.0    19904.0  21248.0  83968.0  21248.0  21248.0      0     0

  9920.0 159040.0   9920.0  960.0  960.0   8000.0    19904.0   318144.0    19904.0    19904.0  21248.0  83968.0  21248.0  21248.0      0     0

  9920.0 159040.0   9920.0  960.0  960.0   8000.0    19904.0   318144.0    19904.0    19904.0  21248.0  83968.0  21248.0  21248.0      0     0

  9920.0 159040.0   9920.0  960.0  960.0   8000.0    19904.0   318144.0    19904.0    19904.0  21248.0  83968.0  21248.0  21248.0      0     0

 

C）、Jmap 查看java程序的内存分配的详细情况

查看堆内存中的对象数目、大小统计直方图，如果带上live则只统计活对象

[root@hadoop1 ~]# jmap  -histo  17319

 

 num     #instances         #bytes  class name

----------------------------------------------

   1:          5577         719008  <methodKlass>

   2:          5577         638736  <constMethodKlass>

   3:           372         435312  <constantPoolKlass>

   4:           335         268448  <constantPoolCacheKlass>

   5:             8         266944  [I

   6:           372         254408  <instanceKlassKlass>

   ***********************************************

 

 

[root@hadoop1 ~]# jmap  -histo:live  17319 | more

 

查看进程堆内存使用情况，包括使用的GC算法、堆配置参数和各代中堆内存使用情况

[root@hadoop1 ~]# jmap -heap 17319

 

内存模型图解

Java程序在运行时会在内存中获取一定大小的内存的大小，虚拟机再把这些区域分成不同的数据区，这些区域管理者不同的功能，有的管理者创建的时间，销毁的时间，有的区域随着虚拟机的创建而存在，还有的区域伴随着用户的而操作而一直执行者，并把这些区域称作为java的区域。

 

1-1）、内存的模拟图

 

 

 

 

 

如上图所示，Java虚拟机运行时数据区域被分为五个区域：

1. 方法区(Method Area)：用于存储类结构信息的地方，包括常量池、静态变量、构造函数等。虽然JVM规范把方法区描述为堆的一个逻辑部分，它有个别名non-heap（非堆）。方法区还包含一个运行时常量池。

 

1. java堆(Heap)：存储java实例或者对象的地方。这块是GC的主要区域（后面解释）。从存储的内容我们可以很容易知道，方法区和堆是被所有java线程共享的。

 

1. java栈(Stack)：java栈总是和线程关联在一起，每当创建一个线程时，JVM就会为这个线程创建一个对应的java栈。在这个java栈中又会包含多个栈帧，每运行一个方法就创建一个栈帧，用于存储局部变量表、操作栈、方法返回值等。每一个方法从调用直至执行完成的过程，就对应一个栈帧在java栈中入栈到出栈的过程。所以java栈是线程私有的。

 

1. 程序计数器(PC Register)：用于保存当前线程执行的内存地址。由于JVM程序是多线程执行的（线程轮流切换），所以为了保证线程切换回来后，还能恢复到原先状态，就需要一个独立的计数器，记录之前中断的地方，程序计数器也是线程私有的。 

 

1. 本地方法栈(Native Method Stack)：和java栈的作用差不多，只不过是为JVM使用到的native方法服务的。

 

 

 

 

 

1-2）、堆(Heep)

    对于大多数的JAVA程序来说Java Heap实在JAVA虚拟机上管理内存中运行最大的一块

该区域伴随着虚拟机的启动而存在，java  heep可以处理上不连续的内存空间，只要是逻辑上是连续的即可，实际中我们创建的对象与数组都是放在堆里面。

 

    新生代、老生代、永久代的概念就是在堆里面。

 

 

1-3）、栈（Stack）

相对于Java Heap来讲，Java Stack是线程私有的，她的生命周期与线程相同。Java Stack描述的是Java方法执行时的内存模型，每个方法执行时都会创建一个栈帧（Stack Frame）用语存储局部变量表、操作数栈、动态链接、方法出口等信息。

 

 

 

在上图中可以看出每一个线程在执行时，都意味着有一个栈帧在当前线程中出栈与入栈

 

 

GC算法

1-1）、标记清除算法（Mark-Sweep）

1、标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象

2、在标记完成后统一回收所有被标记的对象

 

缺点：标记清除之后会产生大量不连续的内存碎片

 

空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

1-2）、复制算法（Copying）

1、将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。

2、当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

 

优点：不会产生内存碎片等

缺点：可用内存缩小为了原来的一半。

复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低

 

1-3）、标记-整理算法（Mark-Compact）

1、标记

2、让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存

 

此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。

 

 

垃圾回收器

1-1）、分代收集方法论

1、概述

分代收集，是当前商业虚拟机常用的垃圾收集算法。

分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。

 

具体来说？

在java程序运行的过程中，会产生大量的对象，因每个对象所能承担的职责不同所具有的功能不同所以也有着不一样的生命周期，有的对象生命周期较长，比如Http请求中的Session对象，线程，Socket连接等；有的对象生命周期较短，比如String对象，由于其不变类的特性，有的在使用一次后即可回收。

 

试想，如果不进行对象存活时间的区分，每次垃圾回收都是对整个堆空间进行回收，那么消耗的时间相对会很长，而且对于存活时间较长的对象进行的扫描工作等都是徒劳。

因此就需要引入分治的思想，所谓分治的思想就是因地制宜，将对象进行代的划分，把不同生命周期的对象放在不同的代上使用不同的垃圾回收方式。

 

如何划分？

将对象按其生命周期的不同划分成：年轻代(Young Generation)、年老代(Old Generation)、持久代(Permanent Generation)。其中持久代主要存放的是类信息，所以与java对象的回收关系不大，与回收息息相关的是年轻代和年老代。

 

 

1-2）、分代收集详述

 年轻代<复制算法>：是所有新对象产生的地方。

年轻代被分为3个部分——Enden区和两个Survivor区（From和to）

当Eden区被对象填满时，就会执行Minor GC，并把所有存活下来的对象转移到其中一个survivor区（from区或to区）。这样在一段时间内，总会有一个空的survivor区。经过多次GC周期后，仍然存活下来的对象会被转移到年老代内存空间。通常这是在年轻代有资格提升到年老代前通过设定年龄阈值来完成的。

需要注意，Survivor的两个区是对称的，没先后关系，from和to是相对的。

 

年老代<标记-整理（Mark-Sweep）>：年轻代中经历了N次回收后仍没被清除的对象

可以说他们都是久经沙场而不亡的一代，都是生命周期较长的对象。对于年老代和永久代，就不能再采用像年轻代中那样搬移腾挪的回收算法。

在老年代内存被占满时通常会触发Full GC,回收整个堆内存。

 

永久代：用于存放静态文件，比如java类、方法等。

持久代对垃圾回收没有显著的影响。  

 

分代回收的效果图如下：

 

 

 

 

 

 

 

1-3）、垃圾收集器概览

 

1-4）、Serial收集器

1、是一个单线程的收集器，“Stop The World”

2、对于运行在Client模式下的虚拟机来说是一个很好的选择

4、简单而高效

 

1-5）、ParNew收集器

1、Serial串行收集器的多线程版本

2、单CPU不如Serial

3、Server模式下新生代首选,目前只有它能与CMS收集器配合工作

4、使用-XX：+UseConcMarkSweepGC选项后的默认新生代收集器，也可以使用-XX：+UseParNewGC选项来强制指定它。

5、-XX：ParallelGCThreads：限制垃圾收集的线程数。

 

 

 

1-6）、Parallel Scavenge收集器

新生代收集器，复制算法，并行的多线程收集器

目标是达到一个可控制的吞吐量（Throughput）。

吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

两个参数用于精确控制吞吐量:

-XX：MaxGCPauseMillis是控制最大垃圾收集停顿时间

-XX：GCTimeRatio直接设置吞吐量大小

-XX：+UseAdaptiveSizePolicy:动态设置新生代大小、Eden与Survivor区的比例、晋升老年代对象年龄

并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。

并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。

 

1-7）、Serial Old收集器

1、Serial收集器的老年代版本，它同样是一个单线程收集器，使用“标记-整理”算法。

2、主要意义也是在于给Client模式下的虚拟机使用。

3、如果在Server模式下，那么它主要还有两大用途：

    一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用[1]，

    另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

 

 

 

1-8）、Parallel Old收集器

1、Parallel Scavenge并行收集器的老年代版本，使用多线程和“标记-整理”算法。

2、在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

 

 

1-9）、CMS(并发GC)收集器

CMS收集器一款优秀的收集器

以获取最短回收停顿时间为目标的收集器。

非常符合互联网站或者B/S系统的服务端上，重视服务的响应速度，希望系统停顿时间最短的应用

基于“标记—清除”算法实现的

CMS收集器的内存回收过程是与用户线程一起并发执行的

 

它的运作过程分为4个步骤，包括：

①初始标记，“Stop The World”，只是标记一下GC Roots能直接关联到的对象，速度很快

②并发标记，并发标记阶段就是进行GC RootsTracing的过程

③.重新标记，Stop The World”，是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，但远比并发标记的时间短

④.并发清除（CMS concurrent sweep）

 

优缺点：

优点——并发收集、低停顿

缺点——对CPU资源非常敏感。

           无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。

       

 

 

1-10）、GF(Garbage-First)收集器

1、当今收集器技术发展的最前沿成果之一

2、G1是一款面向服务端应用的垃圾收集器。

3、优点：

        并行与并发：充分利用多CPU、多核环境下的硬件优势

        分代收集：不需要其他收集器配合就能独立管理整个GC堆

        空间整合：“标记—整理”算法实现的收集器，局部上基于“复制”算法不会产生内存空间碎片            

        可预测的停顿：能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒

4、G1收集器的运作大致可划分为以下几个步骤：

        初始标记：标记一下GC Roots能直接关联到的对象，需要停顿线程，但耗时很短

        并发标记：是从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行

        最终标记：修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录

        筛选回收：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划

 

 

垃圾收集器参数总结

-XX:+<option> 启用选项

-XX:-<option> 不启用选项

-XX:<option>=<number> 

-XX:<option>=<string>

 

参数	描述
-XX:+UseSerialGC	Jvm运行在Client模式下的默认值，打开此开关后，使用Serial + Serial Old的收集器组合进行内存回收
-XX:+UseParNewGC	打开此开关后，使用ParNew + Serial Old的收集器进行垃圾回收
-XX:+UseConcMarkSweepGC	使用ParNew + CMS +  Serial Old的收集器组合进行内存回收，Serial Old作为CMS出现“Concurrent Mode Failure”失败后的后备收集器使用。
-XX:+UseParallelGC	Jvm运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge +  Serial Old的收集器组合进行回收
-XX:+UseParallelOldGC	使用Parallel Scavenge +  Parallel Old的收集器组合进行回收
-XX:SurvivorRatio	新生代中Eden区域与Survivor区域的容量比值，默认为8，代表Eden:Subrvivor = 8:1
-XX:PretenureSizeThreshold	直接晋升到老年代对象的大小，设置这个参数后，大于这个参数的对象将直接在老年代分配
-XX:MaxTenuringThreshold	晋升到老年代的对象年龄，每次Minor GC之后，年龄就加1，当超过这个参数的值时进入老年代
-XX:UseAdaptiveSizePolicy	动态调整java堆中各个区域的大小以及进入老年代的年龄
-XX:+HandlePromotionFailure	是否允许新生代收集担保，进行一次minor gc后, 另一块Survivor空间不足时，将直接会在老年代中保留
-XX:ParallelGCThreads	设置并行GC进行内存回收的线程数
-XX:GCTimeRatio	GC时间占总时间的比列，默认值为99，即允许1%的GC时间，仅在使用Parallel Scavenge 收集器时有效
-XX:MaxGCPauseMillis	设置GC的最大停顿时间，在Parallel Scavenge 收集器下有效
-XX:CMSInitiatingOccupancyFraction	设置CMS收集器在老年代空间被使用多少后出发垃圾收集，默认值为68%，仅在CMS收集器时有效，-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSCompactAtFullCollection	由于CMS收集器会产生碎片，此参数设置在垃圾收集器后是否需要一次内存碎片整理过程，仅在CMS收集器时有效
-XX:+CMSFullGCBeforeCompaction	设置CMS收集器在进行若干次垃圾收集后再进行一次内存碎片整理过程，通常与UseCMSCompactAtFullCollection参数一起使用
-XX:+UseFastAccessorMethods	原始类型优化
-XX:+DisableExplicitGC	是否关闭手动System.gc
-XX:+CMSParallelRemarkEnabled	降低标记停顿
-XX:LargePageSizeInBytes	内存页的大小不可设置过大，会影响Perm的大小，-XX:LargePageSizeInBytes=128m

 

Client、Server模式默认GC

	新生代GC方式	老年代和持久代GC方式
Client	Serial 串行GC	Serial Old 串行GC
Server	Parallel Scavenge  并行回收GC	Parallel Old 并行GC

 

Sun/oracle JDK GC组合方式

	新生代GC方式	老年代和持久代GC方式
-XX:+UseSerialGC	Serial 串行GC	Serial Old 串行GC
-XX:+UseParallelGC	Parallel Scavenge  并行回收GC	Serial Old  并行GC
-XX:+UseConcMarkSweepGC	ParNew 并行GC	CMS 并发GC  当出现“Concurrent Mode Failure”时 采用Serial Old 串行GC
-XX:+UseParNewGC	ParNew 并行GC	Serial Old 串行GC
-XX:+UseParallelOldGC	Parallel Scavenge  并行回收GC	Parallel Old 并行GC
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC	Serial 串行GC	CMS 并发GC  当出现“Concurrent Mode Failure”时 采用Serial Old 串行GC

 

 

 

 

 

 

 

收集器设置：

-XX:+UseSerialGC:年轻串行（Serial），老年串行（Serial Old）

-XX:+UseParNewGC:年轻并行（ParNew），老年串行（Serial Old）

-XX:+UseConcMarkSweepGC:年轻并行（ParNew），老年串行（CMS），备份（Serial Old）

-XX:+UseParallelGC:年轻并行吞吐（Parallel Scavenge），老年串行（Serial Old）

-XX:+UseParalledlOldGC:年轻并行吞吐（Parallel Scavenge），老年并行吞吐（Parallel Old）

收集器参数：

 

-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。

-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间

-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。

-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

 

 

JVM参数列表

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m  -XX:MaxTenuringThreshold=0

-Xmx3550m：最大堆内存为3550M。

-Xms3550m：初始堆内存为3550m。

此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。

-Xmn2g：设置年轻代大小为2G。

整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。

-Xss128k：设置每个线程的堆栈大小。

JDK5.0以后每个线程堆栈大小为1M，在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在 3000~5000左右。

-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5

-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。

设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6

-XX:MaxPermSize=16m:设置持久代大小为16m。

-XX:MaxTenuringThreshold=15：设置垃圾最大年龄。

如果设置为0的话，则年轻代对象不经过Survivor区，直 接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象 再年轻代的存活时间，增加在年轻代即被回收的概论。

 

收集器设置

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

-XX:+UseParallelGC:设置并行收集器

-XX:+UseParalledlOldGC:设置并行年老代收集器

-XX:+UseConcMarkSweepGC:设置并发收集器

垃圾回收统计信息

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

并行收集器设置

-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。

-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间

-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

并发收集器设置

-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。

-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。

查找占用比较耗时的进程

1-1）、先用top命令查找出最耗时的JAVA进程号
# top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
2232 root 20 0 5915768 607124 17240 S 8.6 3.8 4:49.39 java 
29719 hbase 20 0 4117880 716964 34732 S 2.7 4.4 0:30.95 java 
24265 hdfs 20 0 2967592 342520 28220 S 2.0 2.1 0:16.28 java 
81839 oozie 20 0 5798504 497616 39468 S 2.0 3.1 0:21.52 java 
30510 ams 20 0 3529116 533008 27036 S 1.7 3.3 0:47.99 java 
***************
1-2）、把当前的PID转换成16进制
# printf "%x\n" 2232
8b8
1-3）、查看当前耗时的进程
# jstack 2232 | fgrep -A10 8b8
- parking to wait for <0x00000000a339d8b8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:492)
at java.util.concurrent.LinkedBlockingDeque.take(LinkedBlockingDeque.java:680)
at sun.nio.fs.AbstractWatchService.take(AbstractWatchService.java:118)
at org.apache.ambari.server.view.ViewDirectoryWatcher$2.run(ViewDirectoryWatcher.java:112)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)