6月27日任务2

3 jmx监控tomcat

http://blog.csdn.net/l1028386804/article/details/51547408

import java.lang.management.MemoryUsage;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Formatter;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;  

import javax.management.MBeanAttributeInfo;
import javax.management.MBeanInfo;
import javax.management.MBeanServerConnection;
import javax.management.ObjectInstance;
import javax.management.ObjectName;
import javax.management.openmbean.CompositeDataSupport;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
/**
 * @author liuyazhuang
 * @date 2016-05-31
 */
public class JMXTest {  

    /**
     * main方法
     * @param args
     */
    public static void main(String[] args) {
        try {  

            String jmxURL = "service:jmx:rmi:///jndi/rmi://127.0.0.1:8999/jmxrmi";  

            JMXServiceURL serviceURL = new JMXServiceURL(jmxURL);  

            Map map = new HashMap();
            String[] credentials = new String[] { "monitorRole", "tomcat" };
            map.put("jmx.remote.credentials", credentials);
            JMXConnector connector = JMXConnectorFactory.connect(serviceURL,
                    map);
            MBeanServerConnection mbsc = connector.getMBeanServerConnection();  

            // 端口最好是动态取得
            ObjectName threadObjName = new ObjectName(
                    "Catalina:type=ThreadPool,name=http-8080");
            MBeanInfo mbInfo = mbsc.getMBeanInfo(threadObjName);  

            String attrName = "currentThreadCount";// tomcat的线程数对应的属性值
            MBeanAttributeInfo[] mbAttributes = mbInfo.getAttributes();
            System.out.println("currentThreadCount:"
                    + mbsc.getAttribute(threadObjName, attrName));  

            // heap
            for (int j = 0; j < mbsc.getDomains().length; j++) {
                System.out.println("###########" + mbsc.getDomains()[j]);
            }
            Set MBeanset = mbsc.queryMBeans(null, null);
            System.out.println("MBeanset.size() : " + MBeanset.size());
            Iterator MBeansetIterator = MBeanset.iterator();
            while (MBeansetIterator.hasNext()) {
                ObjectInstance objectInstance = (ObjectInstance) MBeansetIterator
                        .next();
                ObjectName objectName = objectInstance.getObjectName();
                String canonicalName = objectName.getCanonicalName();
                System.out.println("canonicalName : " + canonicalName);
                if (canonicalName
                        .equals("Catalina:host=localhost,type=Cluster")) {
                    // Get details of cluster MBeans
                    System.out.println("Cluster MBeans Details:");
                    System.out
                            .println("=========================================");
                    // getMBeansDetails(canonicalName);
                    String canonicalKeyPropList = objectName
                            .getCanonicalKeyPropertyListString();
                }
            }
            // ------------------------- system ----------------------
            ObjectName runtimeObjName = new ObjectName("java.lang:type=Runtime");
            System.out.println("厂商:"
                    + (String) mbsc.getAttribute(runtimeObjName, "VmVendor"));
            System.out.println("程序:"
                    + (String) mbsc.getAttribute(runtimeObjName, "VmName"));
            System.out.println("版本:"
                    + (String) mbsc.getAttribute(runtimeObjName, "VmVersion"));
            Date starttime = new Date((Long) mbsc.getAttribute(runtimeObjName,
                    "StartTime"));
            SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
            System.out.println("启动时间:" + df.format(starttime));  

            Long timespan = (Long) mbsc.getAttribute(runtimeObjName, "Uptime");
            System.out.println("连续工作时间:" + JMXTest.formatTimeSpan(timespan));
            // ------------------------ JVM -------------------------
            // 堆使用率
            ObjectName heapObjName = new ObjectName("java.lang:type=Memory");
            MemoryUsage heapMemoryUsage = MemoryUsage
                    .from((CompositeDataSupport) mbsc.getAttribute(heapObjName,
                            "HeapMemoryUsage"));
            long maxMemory = heapMemoryUsage.getMax();// 堆最大
            long commitMemory = heapMemoryUsage.getCommitted();// 堆当前分配
            long usedMemory = heapMemoryUsage.getUsed();
            System.out.println("heap:" + (double) usedMemory * 100
                    / commitMemory + "%");// 堆使用率  

            MemoryUsage nonheapMemoryUsage = MemoryUsage
                    .from((CompositeDataSupport) mbsc.getAttribute(heapObjName,
                            "NonHeapMemoryUsage"));
            long noncommitMemory = nonheapMemoryUsage.getCommitted();
            long nonusedMemory = heapMemoryUsage.getUsed();
            System.out.println("nonheap:" + (double) nonusedMemory * 100
                    / noncommitMemory + "%");  

            ObjectName permObjName = new ObjectName(
                    "java.lang:type=MemoryPool,name=Perm Gen");
            MemoryUsage permGenUsage = MemoryUsage
                    .from((CompositeDataSupport) mbsc.getAttribute(permObjName,
                            "Usage"));
            long committed = permGenUsage.getCommitted();// 持久堆大小
            long used = heapMemoryUsage.getUsed();//
            System.out.println("perm gen:" + (double) used * 100 / committed
                    + "%");// 持久堆使用率  

            // -------------------- Session ---------------
            ObjectName managerObjName = new ObjectName(
                    "Catalina:type=Manager,*");
            Set<ObjectName> s = mbsc.queryNames(managerObjName, null);
            for (ObjectName obj : s) {
                System.out.println("应用名:" + obj.getKeyProperty("path"));
                ObjectName objname = new ObjectName(obj.getCanonicalName());
                System.out.println("最大会话数:"
                        + mbsc.getAttribute(objname, "maxActiveSessions"));
                System.out.println("会话数:"
                        + mbsc.getAttribute(objname, "activeSessions"));
                System.out.println("活动会话数:"
                        + mbsc.getAttribute(objname, "sessionCounter"));
            }  

            // ----------------- Thread Pool ----------------
            ObjectName threadpoolObjName = new ObjectName(
                    "Catalina:type=ThreadPool,*");
            Set<ObjectName> s2 = mbsc.queryNames(threadpoolObjName, null);
            for (ObjectName obj : s2) {
                System.out.println("端口名:" + obj.getKeyProperty("name"));
                ObjectName objname = new ObjectName(obj.getCanonicalName());
                System.out.println("最大线程数:"
                        + mbsc.getAttribute(objname, "maxThreads"));
                System.out.println("当前线程数:"
                        + mbsc.getAttribute(objname, "currentThreadCount"));
                System.out.println("繁忙线程数:"
                        + mbsc.getAttribute(objname, "currentThreadsBusy"));
            }  

        } catch (Exception e) {
            e.printStackTrace();
        }
    }  

    public static String formatTimeSpan(long span) {
        long minseconds = span % 1000;  

        span = span / 1000;
        long seconds = span % 60;  

        span = span / 60;
        long mins = span % 60;  

        span = span / 60;
        long hours = span % 24;  

        span = span / 24;
        long days = span;
        return (new Formatter()).format("%1$d天 %2$02d:%3$02d:%4$02d.%5$03d",
                days, hours, mins, seconds, minseconds).toString();
    }
}

4 jvm性能调优监控工具jps/jstack/jmap/jhat/jstat

http://blog.csdn.net/wisgood/article/details/25343845
JDK本身提供了很多方便的JVM性能调优监控工具，除了集成式的VisualVM和jConsole外，还有jps、jstack、jmap、jhat、jstat等小巧的工具，本博客希望能起抛砖引玉之用，让大家能开始对JVM性能调优的常用工具有所了解。
现实企业级Java开发中，有时候我们会碰到下面这些问题：

OutOfMemoryError，内存不足

内存泄露

线程死锁

锁争用（Lock Contention）

Java进程消耗CPU过高

......

这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。本文将对一些常用的JVM性能调优监控工具进行介绍，希望能起抛砖引玉之用。本文参考了网上很多资料，难以一一列举，在此对这些资料的作者表示感谢！关于JVM性能调优相关的资料，请参考文末。

 jps(Java Virtual Machine Process Status Tool)

jps主要用来输出JVM中运行的进程状态信息。语法格式如下：

jps [options] [hostid]

如果不指定hostid就默认为当前主机或服务器。

命令行参数选项说明如下：

-q 不输出类名、Jar名和传入main方法的参数

-m 输出传入main方法的参数

-l 输出main类或Jar的全限名

-v 输出传入JVM的参数

比如下面：

[email protected]:/# jps -m -l

2458 org.artifactory.standalone.main.Main /usr/local/artifactory-2.2.5/etc/jetty.xml

29920 com.sun.tools.hat.Main -port 9998 /tmp/dump.dat

3149 org.apache.catalina.startup.Bootstrap start

30972 sun.tools.jps.Jps -m -l

8247 org.apache.catalina.startup.Bootstrap start

25687 com.sun.tools.hat.Main -port 9999 dump.dat

21711 mrf-center.jar

B、 jstack

jstack主要用来查看某个Java进程内的线程堆栈信息。语法格式如下：

jstack [option] pid

jstack [option] executable core

jstack [option] [[email protected]]remote-hostname-or-ip

命令行参数选项说明如下：

-l long listings，会打印出额外的锁信息，在发生死锁时可以用jstack -l pid来观察锁持有情况

-m mixed mode，不仅会输出Java堆栈信息，还会输出C/C++堆栈信息（比如Native方法）
jstack可以定位到线程堆栈，根据堆栈信息我们可以定位到具体代码，所以它在JVM性能调优中使用得非常多。下面我们来一个实例找出某个Java进程中最耗费CPU的Java线程并定位堆栈信息，用到的命令有ps、top、printf、jstack、grep。

第一步先找出Java进程ID，我部署在服务器上的Java应用名称为mrf-center：

[email protected]:/# ps -ef | grep mrf-center | grep -v grep

root     21711     1  1 14:47 pts/3    00:02:10 java -jar mrf-center.jar

得到进程ID为21711，第二步找出该进程内最耗费CPU的线程，可以使用ps -Lfp pid或者ps -mp pid -o THREAD, tid, time或者top -Hp pid，我这里用第三个，输出如下：

JVM性能调优监控工具jps、jstack、jmap、jhat、jstat使用详解

TIME列就是各个Java线程耗费的CPU时间，CPU时间最长的是线程ID为21742的线程，用

printf "%x\n" 21742

得到21742的十六进制值为54ee，下面会用到。

OK，下一步终于轮到jstack上场了，它用来输出进程21711的堆栈信息，然后根据线程ID的十六进制值grep，如下：

[email protected]:/# jstack 21711 | grep 54ee

"PollIntervalRetrySchedulerThread" prio=10 tid=0x00007f950043e000 nid=0x54ee in Object.wait() [0x00007f94c6eda000]

可以看到CPU消耗在PollIntervalRetrySchedulerThread这个类的Object.wait()，我找了下我的代码，定位到下面的代码：

// Idle wait

getLog().info("Thread [" + getName() + "] is idle waiting...");

schedulerThreadState = PollTaskSchedulerThreadState.IdleWaiting;

long now = System.currentTimeMillis();

long waitTime = now + getIdleWaitTime();

long timeUntilContinue = waitTime - now;

synchronized(sigLock) {

    try {

        if(!halted.get()) {

            sigLock.wait(timeUntilContinue);

        }

    } 

    catch (InterruptedException ignore) {

    }

}

它是轮询任务的空闲等待代码，上面的sigLock.wait(timeUntilContinue)就对应了前面的Object.wait()。

 jmap（Memory Map）和jhat（Java Heap Analysis Tool）

jmap用来查看堆内存使用状况，一般结合jhat使用。
jmap语法格式如下：

jmap [option] pid

jmap [option] executable core

jmap [option] [[email protected]]remote-hostname-or-ip
如果运行在64位JVM上，可能需要指定-J-d64命令选项参数。

jmap -permstat pid

打印进程的类加载器和类加载器加载的持久代对象信息，输出：类加载器名称、对象是否存活（不可靠）、对象地址、父类加载器、已加载的类大小等信息，

如下图：

JVM性能调优监控工具jps、jstack、jmap、jhat、jstat使用详解

使用jmap -heap pid查看进程堆内存使用情况，包括使用的GC算法、堆配置参数和各代中堆内存使用情况。比如下面的例子：

[email protected]:/# jmap -heap 21711

Attaching to process ID 21711, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 20.10-b01

using thread-local object allocation.

Parallel GC with 4 thread(s)

Heap Configuration:

   MinHeapFreeRatio = 40

   MaxHeapFreeRatio = 70

   MaxHeapSize      = 2067791872 (1972.0MB)

   NewSize          = 1310720 (1.25MB)

   MaxNewSize       = 17592186044415 MB

   OldSize          = 5439488 (5.1875MB)

   NewRatio         = 2

   SurvivorRatio    = 8

   PermSize         = 21757952 (20.75MB)

   MaxPermSize      = 85983232 (82.0MB)

Heap Usage:

PS Young Generation

Eden Space:

   capacity = 6422528 (6.125MB)

   used     = 5445552 (5.1932830810546875MB)

   free     = 976976 (0.9317169189453125MB)

   84.78829520089286% used

From Space:

   capacity = 131072 (0.125MB)

   used     = 98304 (0.09375MB)

   free     = 32768 (0.03125MB)

   75.0% used

To Space:

   capacity = 131072 (0.125MB)

   used     = 0 (0.0MB)

   free     = 131072 (0.125MB)

   0.0% used

PS Old Generation

   capacity = 35258368 (33.625MB)

   used     = 4119544 (3.9287033081054688MB)

   free     = 31138824 (29.69629669189453MB)

   11.683876009235595% used

PS Perm Generation

   capacity = 52428800 (50.0MB)

   used     = 26075168 (24.867218017578125MB)

   free     = 26353632 (25.132781982421875MB)

   49.73443603515625% used

   ....
    使用jmap -histo[:live]

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

[email protected]:/# jmap -histo:live 21711 | more

 num     #instances         #bytes  class name

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

   1:         38445        5597736  <constMethodKlass>

   2:         38445        5237288  <methodKlass>

   3:          3500        3749504  <constantPoolKlass>

   4:         60858        3242600  <symbolKlass>

   5:          3500        2715264  <instanceKlassKlass>

   6:          2796        2131424  <constantPoolCacheKlass>

   7:          5543        1317400  [I

   8:         13714        1010768  [C

   9:          4752        1003344  [B

  10:          1225         639656  <methodDataKlass>

  11:         14194         454208  java.lang.String

  12:          3809         396136  java.lang.Class

  13:          4979         311952  [S

  14:          5598         287064  [[I

  15:          3028         266464  java.lang.reflect.Method

  16:           280         163520  <objArrayKlassKlass>

  17:          4355         139360  java.util.HashMap$Entry

  18:          1869         138568  [Ljava.util.HashMap$Entry;

  19:          2443          97720  java.util.LinkedHashMap$Entry

  20:          2072          82880  java.lang.ref.SoftReference

  21:          1807          71528  [Ljava.lang.Object;

  22:          2206          70592  java.lang.ref.WeakReference

  23:           934          52304  java.util.LinkedHashMap

  24:           871          48776  java.beans.MethodDescriptor

  25:          1442          46144  java.util.concurrent.ConcurrentHashMap$HashEntry

  26:           804          38592  java.util.HashMap

  27:           948          37920  java.util.concurrent.ConcurrentHashMap$Segment

  28:          1621          35696  [Ljava.lang.Class;

  29:          1313          34880  [Ljava.lang.String;

  30:          1396          33504  java.util.LinkedList$Entry

  31:           462          33264  java.lang.reflect.Field

  32:          1024          32768  java.util.Hashtable$Entry

  33:           948          31440  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;

class name是对象类型，说明如下：

B  byte

C  char

D  double

F  float

I  int

J  long

Z  boolean

[  数组，如[I表示int[]

[L+类名 其他对象

还有一个很常用的情况是：用jmap把进程内存使用情况dump到文件中，再用jhat分析查看。jmap进行dump命令格式如下：

jmap -dump:format=b,file=dumpFileName

我一样地对上面进程ID为21711进行Dump：

[email protected]:/# jmap -dump:format=b,file=/tmp/dump.dat 21711     

Dumping heap to /tmp/dump.dat ...

Heap dump file created

dump出来的文件可以用MAT、VisualVM等工具查看，这里用jhat查看：

[email protected]:/# jhat -port 9998 /tmp/dump.dat

Reading from /tmp/dump.dat...

Dump file created Tue Jan 28 17:46:14 CST 2014

Snapshot read, resolving...

Resolving 132207 objects...

Chasing references, expect 26 dots..........................

Eliminating duplicate references..........................

Snapshot resolved.

Started HTTP server on port 9998

Server is ready.

然后就可以在浏览器中输入主机地址:9998查看了：

JVM性能调优监控工具jps、jstack、jmap、jhat、jstat使用详解

上面红线框出来的部分大家可以自己去摸索下，最后一项支持OQL（对象查询语言）。

D、jstat（JVM统计监测工具）

语法格式如下：

jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]

vmid是虚拟机ID，在Linux/Unix系统上一般就是进程ID。interval是采样时间间隔。count是采样数目。比如下面输出的是GC信息，采样时间间隔为250ms，采样数为4：

[email protected]:/# jstat -gc 21711 250 4

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

192.0  192.0   64.0   0.0    6144.0   1854.9   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649

192.0  192.0   64.0   0.0    6144.0   1972.2   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649

192.0  192.0   64.0   0.0    6144.0   1972.2   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649

192.0  192.0   64.0   0.0    6144.0   2109.7   32000.0     4111.6   55296.0 25472.7    702    0.431   3      0.218    0.649

要明白上面各列的意义，先看JVM堆内存布局：

JVM性能调优监控工具jps、jstack、jmap、jhat、jstat使用详解
可以看出：

堆内存 = 年轻代 + 年老代 + 永久代

年轻代 = Eden区 + 两个Survivor区（From和To）

现在来解释各列含义：

S0C、S1C、S0U、S1U：Survivor 0/1区容量（Capacity）和使用量（Used）

EC、EU：Eden区容量和使用量

OC、OU：年老代容量和使用量

PC、PU：永久代容量和使用量

YGC、YGT：年轻代GC次数和GC耗时

FGC、FGCT：Full GC次数和Full GC耗时

GCT：GC总耗时

其他JVM性能调优参考资料：

《Java虚拟机规范》

《Java Performance》

《Trouble Shooting Guide for JavaSE 6 with HotSpot VM》: http://www.oracle.com/technetwork/java/javase/tsg-vm-149989.pdf

《Effective Java》

VisualVM: http://docs.oracle.com/javase/7/docs/technotes/guides/visualvm/

jConsole: http://docs.oracle.com/javase/1.5.0/docs/guide/management/jconsole.html

Monitoring and Managing JavaSE 6 Applications: http://www.oracle.com/technetwork/articles/javase/monitoring-141801.html

jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令

http://guafei.iteye.com/blog/1815222
1．Jstack
1.1 jstack能得到运行java程序的java stack和native stack的信息。可以轻松得知当前线程的运行情况。如下图所示

注：这个和thread dump是同样的结果。但是thread dump是用kill -3 pid命令，还是服务器上面少用kill为妙

1.2 命名行格式

jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [[email protected]]remote-hostname-or-IP

最常用的还是jstack pid

1.3 在thread dump中，要留意下面几种状态
死锁，Deadlock（重点关注）
等待资源，Waiting on condition（重点关注）
? 等待获取监视器，Waiting on monitor entry（重点关注）
阻塞，Blocked（重点关注）
? 执行中，Runnable
? 暂停，Suspended
? 对象等待中，Object.wait() 或 TIMED_WAITING
? 停止，Parked
下面有详细的例子讲这种分析，大家参考原著
http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html

1.4 在thread dump中，有几种线程的定义如下
线程名称所属解释说明
Attach Listener JVM Attach Listener 线程是负责接收到外部的命令，而对该命令进行执行的并且吧结果返回给发送者。通常我们会用一些命令去要求jvm给我们一些反馈信息，如：java -version、jmap、jstack等等。如果该线程在jvm启动的时候没有初始化，那么，则会在用户第一次执行jvm命令时，得到启动。
Signal Dispatcher JVM 前面我们提到第一个Attach Listener线程的职责是接收外部jvm命令，当命令接收成功后，会交给signal dispather 线程去进行分发到各个不同的模块处理命令，并且返回处理结果。 signal dispather线程也是在第一次接收外部jvm命令时，进行初始化工作。
CompilerThread0 JVM 用来调用JITing，实时编译装卸class 。通常，jvm会启动多个线程来处理这部分工作，线程名称后面的数字也会累加，例如：CompilerThread1
Concurrent Mark-Sweep GC Thread JVM 并发标记清除垃圾回收器（就是通常所说的CMS GC）线程，该线程主要针对于老年代垃圾回收。ps：启用该垃圾回收器，需要在jvm启动参数中加上： -XX:+UseConcMarkSweepGC
DestroyJavaVM JVM 执行main()的线程在main执行完后调用JNI中的 jni_DestroyJavaVM() 方法唤起DestroyJavaVM 线程。 JVM在 Jboss 服务器启动之后，就会唤起DestroyJavaVM线程，处于等待状态，等待其它线程（java线程和native线程）退出时通知它卸载JVM。线程退出时，都会判断自己当前是否是整个JVM中最后一个非deamon线程，如果是，则通知DestroyJavaVM 线程卸载JVM。
ps：
扩展一下：
1.如果线程退出时判断自己不为最后一个非deamon线程，那么调用thread->exit(false) ，并在其中抛出thread_end事件，jvm不退出。
2.如果线程退出时判断自己为最后一个非deamon线程，那么调用before_exit() 方法，抛出两个事件：事件1：thread_end 线程结束事件、事件2：VM的death事件。
然后调用thread->exit(true) 方法，接下来把线程从active list卸下，删除线程等等一系列工作执行完成后，则通知正在等待的DestroyJavaVM 线程执行卸载JVM操作。
ContainerBackgroundProcessor 线程 JBOSS 它是一个守护线程, 在jboss服务器在启动的时候就初始化了,主要工作是定期去检查有没有Session过期.过期则清除.
参考：http://liudeh-009.iteye.com/blog/1584876

Dispatcher-Thread-3 线程 Log4j Log4j具有异步打印日志的功能，需要异步打印日志的Appender都需要注册到 AsyncAppender对象里面去，由AsyncAppender进行监听，决定何时触发日志打印操作。 AsyncAppender如果监听到它管辖范围内的Appender有打印日志的操作，则给这个Appender生成一个相应的event，并将该event保存在一个buffuer区域内。 Dispatcher-Thread-3线程负责判断这个event缓存区是否已经满了，如果已经满了，则将缓存区内的所有event分发到Appender容器里面去，那些注册上来的Appender收到自己的event后，则开始处理自己的日志打印工作。 Dispatcher-Thread-3线程是一个守护线程。
Finalizer线程 JVM 这个线程也是在main线程之后创建的，其优先级为10，主要用于在垃圾收集前，调用对象的finalize()方法；关于Finalizer线程的几点：
1) 只有当开始一轮垃圾收集时，才会开始调用finalize()方法；因此并不是所有对象的finalize()方法都会被执行；
2) 该线程也是daemon线程，因此如果虚拟机中没有其他非daemon线程，不管该线程有没有执行完finalize()方法，JVM也会退出；
3) JVM在垃圾收集时会将失去引用的对象包装成Finalizer对象（Reference的实现），并放入ReferenceQueue，由Finalizer线程来处理；最后将该Finalizer对象的引用置为null，由垃圾收集器来回收；
4) JVM为什么要单独用一个线程来执行finalize()方法呢？如果JVM的垃圾收集线程自己来做，很有可能由于在finalize()方法中误操作导致GC线程停止或不可控，这对GC线程来说是一种灾难；
Gang worker#0 JVM JVM 用于做新生代垃圾回收（monir gc）的一个线程。#号后面是线程编号，例如：Gang worker#1
GC Daemon JVM GC Daemon 线程是JVM为RMI提供远程分布式GC使用的，GC Daemon线程里面会主动调用System.gc()方法，对服务器进行Full GC。其初衷是当 RMI 服务器返回一个对象到其客户机（远程方法的调用方）时，其跟踪远程对象在客户机中的使用。当再没有更多的对客户机上远程对象的引用时，或者如果引用的“租借”过期并且没有更新，服务器将垃圾回收远程对象。
不过，我们现在jvm启动参数都加上了-XX:+DisableExplicitGC配置，所以，这个线程只有打酱油的份了。
IdleRemover JBOSS Jboss连接池有一个最小值，该线程每过一段时间都会被Jboss唤起，用于检查和销毁连接池中空闲和无效的连接，直到剩余的连接数小于等于它的最小值。
Java2D Disposer JVM 这个线程主要服务于awt的各个组件。说起该线程的主要工作职责前，需要先介绍一下Disposer类是干嘛的。 Disposer提供一个addRecord方法。如果你想在一个对象被销毁前再做一些善后工作，那么，你可以调用Disposer#addRecord方法，将这个对象和一个自定义的DisposerRecord接口实现类，一起传入进去，进行注册。
Disposer类会唤起“Java2D Disposer”线程，该线程会扫描已注册的这些对象是否要被回收了，如果是，则调用该对象对应的DisposerRecord实现类里面的dispose方法。
Disposer实际上不限于在awt应用场景，只是awt里面的很多组件需要访问很多操作系统资源，所以，这些组件在被回收时，需要先释放这些资源。
InsttoolCacheScheduler_
QuartzSchedulerThread Quartz InsttoolCacheScheduler_QuartzSchedulerThread是Quartz的主线程，它主要负责实时的获取下一个时间点要触发的触发器，然后执行触发器相关联的作业。
原理大致如下：
Spring和Quartz结合使用的场景下，Spring IOC容器初始化时会创建并初始化Quartz线程池（TreadPool），并启动它。刚启动时线程池中每个线程都处于等待状态，等待外界给他分配Runnable（持有作业对象的线程）。
继而接着初始化并启动Quartz的主线程（InsttoolCacheScheduler_QuartzSchedulerThread），该线程自启动后就会处于等待状态。等待外界给出工作信号之后，该主线程的run方法才实质上开始工作。run中会获取JobStore中下一次要触发的作业，拿到之后会一直等待到该作业的真正触发时间，然后将该作业包装成一个JobRunShell对象（该对象实现了Runnable接口，其实看是上面TreadPool中等待外界分配给他的Runnable），然后将刚创建的JobRunShell交给线程池，由线程池负责执行作业。
线程池收到Runnable后，从线程池一个线程启动Runnable，反射调用JobRunShell中的run方法，run方法执行完成之后， TreadPool将该线程回收至空闲线程中。
InsttoolCacheScheduler_Worker-2 Quartz InsttoolCacheScheduler_Worker-2线程就是ThreadPool线程的一个简单实现，它主要负责分配线程资源去执行
InsttoolCacheScheduler_QuartzSchedulerThread线程交给它的调度任务（也就是JobRunShell）。
JBossLifeThread Jboss Jboss主线程启动成功，应用程序部署完毕之后将JBossLifeThread线程实例化并且start，JBossLifeThread线程启动成功之后就处于等待状态，以保持Jboss Java进程处于存活中。所得比较通俗一点，就是Jboss启动流程执行完毕之后，为什么没有结束？就是因为有这个线程hold主了它。牛b吧～～
JBoss System Threads(1)-1 Jboss 该线程是一个socket服务，默认端口号为： 1099。主要用于接收外部naming service（Jboss JNDI）请求。
JCA PoolFiller Jboss 该线程主要为JBoss内部提供连接池的托管。简单介绍一下工作原理：
Jboss内部凡是有远程连接需求的类，都需要实现ManagedConnectionFactory接口，例如需要做JDBC连接的
XAManagedConnectionFactory对象，就实现了该接口。然后将XAManagedConnectionFactory对象，还有其它信息一起包装到InternalManagedConnectionPool对象里面，接着将InternalManagedConnectionPool交给PoolFiller对象里面的列队进行管理。 JCA PoolFiller线程会定期判断列队内是否有需要创建和管理的InternalManagedConnectionPool对象，如果有的话，则调用该对象的fillToMin方法，触发它去创建相应的远程连接，并且将这个连接维护到它相应的连接池里面去。
JDWP Event Helper Thread JVM
JDWP是通讯交互协议，它定义了调试器和被调试程序之间传递信息的格式。它详细完整地定义了请求命令、回应数据和错误代码，保证了前端和后端的JVMTI和JDI的通信通畅。该线程主要负责将JDI事件映射成JVMTI信号，以达到调试过程中操作JVM的目的。

JDWP Transport Listener: dt_socket JVM 该线程是一个Java Debugger的监听器线程，负责受理客户端的debug请求。通常我们习惯将它的监听端口设置为8787。
Low Memory Detector JVM 这个线程是负责对可使用内存进行检测，如果发现可用内存低，分配新的内存空间。
process reaper JVM 该线程负责去执行一个 OS 命令行的操作。
Reference Handler JVM JVM在创建main线程后就创建Reference Handler线程，其优先级最高，为10，它主要用于处理引用对象本身（软引用、弱引用、虚引用）的垃圾回收问题。
Surrogate Locker Thread (CMS) JVM 这个线程主要用于配合CMS垃圾回收器使用，它是一个守护线程，其主要负责处理GC过程中，Java层的Reference（指软引用、弱引用等等）与jvm 内部层面的对象状态同步。这里对它们的实现稍微做一下介绍：这里拿 WeakHashMap做例子，将一些关键点先列出来（我们后面会将这些关键点全部串起来）：

我们知道HashMap用Entry[]数组来存储数据的，WeakHashMap也不例外, 内部有一个Entry[]数组。
WeakHashMap的Entry比较特殊，它的继承体系结构为Entry->WeakReference->Reference 。
Reference 里面有一个全局锁对象：Lock，它也被称为pending_lock. 注意：它是静态对象。
Reference 里面有一个静态变量：pending。
Reference 里面有一个静态内部类：ReferenceHandler的线程，它在static块里面被初始化并且启动，启动完成后处于wait状态，它在一个Lock同步锁模块中等待。
另外，WeakHashMap里面还实例化了一个ReferenceQueue列队，这个列队的作用，后面会提到。
上面关键点就介绍完毕了，下面我们把他们串起来。
假设，WeakHashMap对象里面已经保存了很多对象的引用。 JVM 在进行CMS GC的时候，会创建一个ConcurrentMarkSweepThread（简称CMST）线程去进行GC，ConcurrentMarkSweepThread线程被创建的同时会创建一个SurrogateLockerThread（简称SLT）线程并且启动它，SLT启动之后，处于等待阶段。CMST开始GC时，会发一个消息给SLT让它去获取Java层Reference对象的全局锁：Lock。直到CMS GC完毕之后，JVM 会将WeakHashMap中所有被回收的对象所属的WeakReference容器对象放入到Reference 的pending属性当中（每次GC完毕之后，pending属性基本上都不会为null了），然后通知SLT释放并且notify全局锁:Lock。此时激活了ReferenceHandler线程的run方法，使其脱离wait状态，开始工作了。ReferenceHandler这个线程会将pending中的所有WeakReference对象都移动到它们各自的列队当中，比如当前这个WeakReference属于某个WeakHashMap对象，那么它就会被放入相应的ReferenceQueue列队里面（该列队是链表结构）。当我们下次从WeakHashMap对象里面get、put数据或者调用size方法的时候，WeakHashMap就会将ReferenceQueue列队中的WeakReference依依poll出来去和Entry[]数据做比较，如果发现相同的，则说明这个Entry所保存的对象已经被GC掉了，那么将Entry[]内的Entry对象剔除掉。
taskObjectTimerFactory JVM 顾名思义，该线程就是用来执行任务的。当我们把一个认为交给Timer对象，并且告诉它执行时间，周期时间后，Timer就会将该任务放入任务列队，并且通知taskObjectTimerFactory线程去处理任务，taskObjectTimerFactory线程会将状态为取消的任务从任务列队中移除，如果任务是非重复执行类型的，则在执行完该任务后，将它从任务列队中移除，如果该任务是需要重复执行的，则计算出它下一次执行的时间点。
VM Periodic Task Thread JVM 该线程是JVM周期性任务调度的线程，它由WatcherThread创建，是一个单例对象。该线程在JVM内使用得比较频繁，比如：定期的内存监控、JVM运行状况监控，还有我们经常需要去执行一些jstat 这类命令查看gc的情况，如下：
jstat -gcutil 23483 250 7 这个命令告诉jvm在控制台打印PID为：23483的gc情况，间隔250毫秒打印一次，一共打印7次。
VM Thread JVM 这个线程就比较牛b了，是jvm里面的线程母体，根据hotspot源码（vmThread.hpp）里面的注释，它是一个单例的对象（最原始的线程）会产生或触发所有其他的线程，这个单个的VM线程是会被其他线程所使用来做一些VM操作（如，清扫垃圾等）。
在 VMThread 的结构体里有一个VMOperationQueue列队，所有的VM线程操作(vm_operation)都会被保存到这个列队当中，VMThread 本身就是一个线程，它的线程负责执行一个自轮询的loop函数(具体可以参考：VMThread.cpp里面的void VMThread::loop()) ，该loop函数从VMOperationQueue列队中按照优先级取出当前需要执行的操作对象(VM_Operation)，并且调用VM_Operation->evaluate函数去执行该操作类型本身的业务逻辑。
ps：VM操作类型被定义在vm_operations.hpp文件内，列举几个：ThreadStop、ThreadDump、PrintThreads、GenCollectFull、GenCollectFullConcurrent、CMS_Initial_Mark、CMS_Final_Remark….. 有兴趣的同学，可以自己去查看源文件。
(搬运自 http://blog.csdn.net/a43350860/article/details/8134234 感谢原著作者)

2．Jmap
2.1 得到运行java程序的内存分配的详细情况。例如实例个数，大小等

2.2 命名行格式

jmap [ option ] pid
jmap [ option ] executable core
jmap [ option ] [[email protected]]remote-hostname-or-IP

-dump:[live,]format=b,file=<filename> 使用hprof二进制形式,输出jvm的heap内容到文件=. live子选项是可选的，假如指定live选项,那么只输出活的对象到文件.
-finalizerinfo 打印正等候回收的对象的信息.
-heap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况.
-histo[:live] 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀”*”. 如果live子参数加上后,只统计活的对象数量.
-permstat 打印classload和jvm heap长久层的信息. 包含每个classloader的名字,活泼性,地址,父classloader和加载的class数量. 另外,内部String的数量和占用内存数也会打印出来.
-F 强迫.在pid没有相应的时候使用-dump或者-histo参数. 在这个模式下,live子参数无效.
-h | -help 打印辅助信息
-J 传递参数给jmap启动的jvm.

2.3 使用例子
jmap -histo pid(查看实例)

jmap -dump:format=b,file=heap.bin pid(导出内存，据说对性能有影响，小心使用)
(format=b是通过二进制的意思，但是能不能导出文本文件我没找到，知道的告诉我)
把内存结构全部dump到二进制文件中，通过IBM的HeapAnalyzer和eclipse的MemoryAnalyzer都可以分析内存结构。
这个是我用HeapAnalyzer查看出的我们daily的内存结构，已经列出了可能存在的问题。(这个工具我不熟悉，只供大家参考)

下面是我用eclipse 的MemoryAnalyzer查看内存结构图

上面的是eclipse分析内存泄漏分析出的。这个功能点非常多。可以慢慢学习

3．Jstat
3.1 这是一个比较实用的一个命令，可以观察到classloader，compiler，gc相关信息。可以时时监控资源和性能

3.2 命令格式

-class：统计class loader行为信息
-compile：统计编译行为信息
-gc：统计jdk gc时heap信息
-gccapacity：统计不同的generations（不知道怎么翻译好，包括新生区，老年区，permanent区）相应的heap容量情况
-gccause：统计gc的情况，（同-gcutil）和引起gc的事件
-gcnew：统计gc时，新生代的情况
-gcnewcapacity：统计gc时，新生代heap容量
-gcold：统计gc时，老年区的情况
-gcoldcapacity：统计gc时，老年区heap容量
-gcpermcapacity：统计gc时，permanent区heap容量
-gcutil：统计gc时，heap情况

3.3 输出参数内容

S0  — Heap上的 Survivor space 0 区已使用空间的百分比
S0C：S0当前容量的大小
S0U：S0已经使用的大小
S1  — Heap上的 Survivor space 1 区已使用空间的百分比
S1C：S1当前容量的大小
S1U：S1已经使用的大小
E   — Heap上的 Eden space 区已使用空间的百分比
EC：Eden space当前容量的大小
EU：Eden space已经使用的大小 1．Jstack

例子1

例子2(连续5次)

例子3(PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量)

这个工具的参数非常多，据说基本能覆盖jprofile等收费工具的所有功能了。多用用对于系统调优还是很有帮助的

注1：我们在daily用这样命令时，都要用-F参数的。因为我们的用户都不是启动命令的用户
注2：daily的这些命令好像都没有配置到环境变量里面，这个是我在自己应用机器里面看到的。需要去jdk目录底下执行。Sudo当然是必须的了

5 gvm gc 相关

http://www.cnblogs.com/Mandylover/p/5208055.html
JVM的GC机制及JVM的调优方法
内存管理和垃圾回收是JVM非常关键的点，对Java性能的剖析而言，了解内存管理和垃圾回收的基本策略非常重要。

1.在程序运行过程当中，会创建大量的对象，这些对象，大部分是短周期的对象，小部分是长周期的对象，对于短周期的对象，需要频繁地进行垃圾回收以保证无用对象尽早被释放掉，对于长周期对象，则不需要频率垃圾回收以确保无谓地垃圾扫描检测。为解决这种矛盾，Sun JVM的内存管理采用分代的策略。

1）年轻代(Young Gen)：年轻代主要存放新创建的对象，内存大小相对会比较小，垃圾回收会比较频繁。年轻代分成1个Eden Space和2个Suvivor Space（命名为A和B）
当对象在堆创建时，将进入年轻代的Eden Space。
垃圾回收器进行垃圾回收时，扫描Eden Space和A Suvivor Space，如果对象仍然存活，则复制到B Suvivor Space，如果B Suvivor Space已经满，则复制 Old Gen
扫描A Suvivor Space时，如果对象已经经过了几次的扫描仍然存活，JVM认为其为一个Old对象，则将其移到Old Gen。
扫描完毕后，JVM将Eden Space和A Suvivor Space清空，然后交换A和B的角色（即下次垃圾回收时会扫描Eden Space和BSuvivor Space。

我们可以看到：Young Gen垃圾回收时，采用将存活对象复制到到空的Suvivor Space的方式来确保不存在内存碎片，采用空间换时间的方式来加速内存垃圾回收。
2）年老代(Tenured Gen)：年老代主要存放JVM认为比较old的对象（经过几次的Young Gen的垃圾回收后仍然存在），内存大小相对会比较大，垃圾回收也相对没有那么频繁（譬如可能几个小时一次）。年老代主要采用压缩的方式来避免内存碎片（将存活对象移动到内存片的一边），当然，有些垃圾回收器（譬如CMS垃圾回收器）出于效率的原因，可能会不进行压缩。
3）持久代(Perm Gen)：持久代主要存放类定义、字节码和常量等很少会变更的信息

2.总结

1、对象优先在Eden分配，这里大部分对象具有朝生夕灭的特征，Minor GC主要清理该处
2、大对象（占内存大）、老对象（使用频繁）

3、Survivor无法容纳的对象，将进入老年代，Full GC的主要清理该处

3.JVM有 2个GC线程

第一个线程负责回收Heap的Young区
第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区

JVM(采用分代回收的策略)，用较高的频率对年轻的对象(young generation)进行YGC，而对老对象( tenured generation)较少( tenured generation 满了后才进行)进行Full GC。这样就不需要每次GC都将内存中所有对象都检查一遍。

GC不会在主程序运行期对PermGen Space进行清理，所以如果你的应用中有很多CLASS(特别是动态生成类，当然permgen space存放的内容不仅限于类)的话,就很可能出现PermGen Space错误。

4.jvm的调优

减少FullGC的次数，以为FullGC会暂停程序比较长的时间，如果FullGC的次数比较多。程序就会经常性的假死。

Heap size 设置
JVM 堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。

如果Heap size 设置偏小，GC占用了更多的时间，而应用分配到的执行时间较少。但Heap size 最大不要超过可用物理内存的80%。

具有2G或者更多的物理内存

http://www.xuebuyuan.com/1201516.html

JVM gc参数设置与分析

http://blog.csdn.net/yohoph/article/details/42041729
原文：

http://hi.baidu.com/i1see1you/item/295c1dc81f91ab55bdef69e5

gc日志分析工具: http://qa.blog.163.com/blog/static/19014700220128199421589/

Java GC 日志图解: http://www.chinasb.org/archives/2012/09/4921.shtml

概述

java的最大好处是自动垃圾回收，这样就无需我们手动的释放对象空间了，但是也产生了相应的负效果，gc是需要时间和资源的，不好的gc会严重影响系统的系能，因此良好的gc是JVM的高性能的保证。JVM堆分为新生代，旧生代和年老代，新生代可用的gc方式有：串行gc（Serial Copying），并行回收gc(Parellel Scavenge)，并行gc(ParNew)，旧生代和年老代可用的gc方式有串行gc(Serial MSC),并行gc(Parallel MSC)，并发gc（CMS）。

回收方式的选择

jvm有client和server两种模式，这两种模式的gc默认方式是不同的：

client模式下，新生代选择的是串行gc，旧生代选择的是串行gc

server模式下，新生代选择的是并行回收gc，旧生代选择的是并行gc

一般来说我们系统应用选择有两种方式：吞吐量优先和暂停时间优先，对于吞吐量优先的采用server默认的并行gc方式，对于暂停时间优先的选用并发gc（CMS）方式。

CMS gc

CMS，全称Concurrent Low Pause Collector，是jdk1.4后期版本开始引入的新gc算法，在jdk5和jdk6中得到了进一步改进，它的主要适合场景是对响应时间的重要性需求大于对吞吐量的要求，能够承受垃圾回收线程和应用线程共享处理器资源，并且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured generation的回收，也就是年老代的回收，目标是尽量减少应用的暂停时间，减少full gc发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代。在我们的应用中，因为有缓存的存在，并且对于响应时间也有比较高的要求，因此希望能尝试使用CMS来替代默认的server型JVM使用的并行收集器，以便获得更短的垃圾回收的暂停时间，提高程序的响应性。

CMS并非没有暂停，而是用两次短暂停来替代串行标记整理算法的长暂停，它的收集周期是这样：

初始标记(CMS-initial-mark) -> 并发标记(CMS-concurrent-mark) -> 重新标记(CMS-remark) -> 并发清除(CMS-concurrent-sweep) ->并发重设状态等待下次CMS的触发(CMS-concurrent-reset)。

其中的1，3两个步骤需要暂停所有的应用程序线程的。第一次暂停从root对象开始标记存活的对象，这个阶段称为初始标记；第二次暂停是在并发标记之后，暂停所有应用程序线程，重新标记并发标记阶段遗漏的对象（在并发标记阶段结束后对象状态的更新导致）。第一次暂停会比较短，第二次暂停通常会比较长，并且 remark这个阶段可以并行标记。

而并发标记、并发清除、并发重设阶段的所谓并发，是指一个或者多个垃圾回收线程和应用程序线程并发地运行，垃圾回收线程不会暂停应用程序的执行，如果你有多于一个处理器，那么并发收集线程将与应用线程在不同的处理器上运行，显然，这样的开销就是会降低应用的吞吐量。Remark阶段的并行，是指暂停了所有应用程序后，启动一定数目的垃圾回收进程进行并行标记，此时的应用线程是暂停的。

full gc

full gc是对新生代，旧生代，以及持久代的统一回收，由于是对整个空间的回收，因此比较慢，系统中应当尽量减少full gc的次数。

如下几种情况下会发生full gc：

旧生代空间不足
持久代空间不足
CMS GC时出现了promotion failed和concurrent mode failure
统计得到新生代minor gc时晋升到旧生代的平均大小小于旧生代剩余空间
直接调用System.gc，可以DisableExplicitGC来禁止

存在rmi调用时，默认会每分钟执行一次System.gc，可以通过-Dsun.rmi.dgc.server.gcInterval=3600000来设置大点的间隔。

Gc日志参数

通过在tomcat启动脚本中添加相关参数生成gc日志

-verbose.gc开关可显示GC的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。

打开-xx:+printGCdetails开关，可以详细了解GC中的变化。

打开-XX:+PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自JVM启动以后以秒计量。

最后，通过-xx:+PrintHeapAtGC开关了解堆的更详细的信息。

为了了解新域的情况，可以通过-XX:+PrintTenuringDistribution开关了解获得使用期的对象权。

-Xloggc:$CATALINA_BASE/logs/gc.log gc日志产生的路径

-XX:+PrintGCApplicationStoppedTime 输出GC造成应用暂停的时间

-XX:+PrintGCDateStamps GC发生的时间信息

Opentsdb打开Gc参数

# tsdb.local

# http://opentsdb.net/docs/build/html/user_guide/cli/index.html

GCARGS="-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps
 -XX:+PrintTenuringDistribution -Xloggc:/tmp/tsd-gc-`date

+%s`.log"

if

test  -t 0; then

# if stdin is a tty, don‘t turn on GC logging.

  GCARGS=

fi

# The Sun JDK caches all name resolution results forever, which is stupid.

# This forces you to restart your application if any of the backends change

# IP. Instead tell it to cache names for only 10 minutes at most.

FIX_DNS=‘-Dsun.net.inetaddr.ttl=600‘

JVMARGS="$JVMARGS $GCARGS $FIX_DNS"

常用JVM参数

分析gc日志后，经常需要调整jvm内存相关参数，常用参数如下

-Xms：初始堆大小，默认为物理内存的1/64(<1GB)；默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制

-Xmx：最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制

-Xmn：新生代的内存空间大小，注意：此处的大小是（eden+ 2 survivor space)。与jmap -heap中显示的New gen是不同的。整个堆大小=新生代大小 + 老生代大小 +
永久代大小。在保证堆大小不变的情况下，增大新生代后,将会减小老生代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-XX:SurvivorRatio：新生代中Eden区域与Survivor区域的容量比值，默认值为8。两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。

-Xss：每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。应根据应用的线程所需内存大小进行适当调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。一般小的应用，
如果栈不是很深，
应该是128k够用的，大的应用建议使用256k。这个选项对性能影响比较大，需要严格的测试。和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:"-Xss
is translated in a VM flag named ThreadStackSize”一般设置这个值就可以了。

-XX:PermSize：设置永久代(perm gen)初始值。默认值为物理内存的1/64。

-XX:MaxPermSize：设置持久代最大值。物理内存的1/4。

示例

下面对如下的参数进行分析：

JAVA_OPTS="-server -Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:SurvivorRatio=4

-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log 

-Djava.awt.headless=true 

-XX:+PrintGCTimeStamps -XX:+PrintGCDetails 

-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000

-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15"

-Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m

Xms，即为jvm启动时得JVM初始堆大小,Xmx为jvm的最大堆大小，xmn为新生代的大小，permsize为永久代的初始大小，MaxPermSize为永久代的最大空间。

-XX:SurvivorRatio=4

SurvivorRatio为新生代空间中的Eden区和救助空间Survivor区的大小比值，默认是32，也就是说Eden区是
Survivor区的32倍大小，要注意Survivo是有两个区的，因此Surivivor其实占整个young
genertation的1/34。调小这个参数将增大survivor区，让对象尽量在survitor区呆长一点，减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代，加快年老代的回收频率，减少年老代暴涨的可能性，这个是通过将-XX:SurvivorRatio
设置成比较大的值（比如65536)来做到。

-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log

将虚拟机每次垃圾回收的信息写到日志文件中，文件名由file指定，文件格式是平文件，内容和-verbose:gc输出内容相同。

-Djava.awt.headless=true

Headless模式是系统的一种配置模式。在该模式下，系统缺少了显示设备、键盘或鼠标。

-XX:+PrintGCTimeStamps -XX:+PrintGCDetails

设置gc日志的格式

-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000

指定rmi调用时gc的时间间隔

-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15

采用并发gc方式，经过15次minor gc 后进入年老代

Xms 是指设定程序启动时占用内存大小。一般来讲，大点，程序会启动的快一点，但是也可能会导致机器暂时间变慢。

Xmx 是指设定程序运行期间最大可占用的内存大小。如果程序运行需要占用更多的内存，超出了这个设置值，就会抛出OutOfMemory异常。

Xss 是指设定每个线程的堆栈大小。这个就要依据你的程序，看一个线程大约需要占用多少内存，可能会有多少线程同时运行等。

以上三个参数的设置都是默认以Byte为单位的，也可以在数字后面添加[k/K]或者[m/M]来表示KB或者MB。而且，超过机器本身的内存大小也是不可以的，否则就等着机器变慢而不是程序变慢了。

-Xmsn

Specify the initial size, in bytes, of the memory allocation pool.
This value must be a multiple of 1024 greater than 1MB. Append the
letter k or K to indicate kilobytes, or m or M to indicate megabytes.
The default value is chosen at runtime based on system configuration.
For more information, see HotSpot Ergonomics

Examples:

   -Xms6291456

   -Xms6144k

   -Xms6m

-Xmxn

Specify the maximum size, in bytes, of the memory allocation pool. This value must a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is chosen at runtime based on system configuration. For more information, see HotSpot Ergonomics

Examples:

   -Xmx83886080

   -Xmx81920k

   -Xmx80m

-Xssn

Set thread stack size.

一些常见问题

为了避免Perm区满引起的full gc，建议开启CMS回收Perm区选项：

+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

默认CMS是在tenured generation沾满68%的时候开始进行CMS收集，如果你的年老代增长不是那么快，并且希望降低CMS次数的话，可以适当调高此值：

-XX:CMSInitiatingOccupancyFraction=80

遇到两种fail引起full gc：Prommotion failed和Concurrent mode failed时：

Prommotion failed的日志输出大概是这样：

[ParNew (promotion failed): 320138K->320138K(353920K), 0.2365970 secs]42576.951: [CMS: 1139969K->1120688K( 166784K), 9.2214860 secs] 1458785K->1120688K(2520704K), 9.4584090 secs]

这个问题的产生是由于救助空间不够，从而向年老代转移对象，年老代没有足够的空间来容纳这些对象，导致一次full gc的产生。解决这个问题的办法有两种完全相反的倾向：增大救助空间、增大年老代或者去掉救助空间。

Concurrent mode failed的日志大概是这样的：

(concurrent mode failure): 1228795K->1228598K(1228800K), 7.6748280 secs] 1911483K->1681165K(1911488K), [CMS Perm : 225407K->225394K(262144K)], 7.6751800 secs]

问题的产生原因是由于CMS回收年老代的速度太慢，导致年老代在CMS完成前就被沾满，引起full gc，避免这个现象的产生就是调小-XX:CMSInitiatingOccupancyFraction参数的值，让CMS更早更频繁的触发，降低年老代被沾满的可能。

Gc日志分析工具

GCHisto

http://java.net/projects/gchisto

直接点击gchisto.jar就可以运行，点add载入gc.log

统计了总共gc次数，youngGC次数，FullGC次数，次数的百分比，GC消耗的时间，百分比，平均消耗时间，消耗时间最小最大值等

统计的图形化表示

YoungGC,FullGC不同消耗时间上次数的分布图，勾选可以显示youngGC或fullGC单独的分布情况

整个时间过程详细的gc情况，可以对整个过程进行剖析

GCLogViewer

http://code.google.com/p/gclogviewer/

点击run.bat运行

整个过程gc情况的趋势图，还显示了gc类型，吞吐量，平均gc频率，内存变化趋势等

Tools里还能比较不同gc日志:

HPjmeter

获取地址 http://www.hp.com/go/java

参考文档 http://www.javaperformancetuning.com/tools/hpjtune/index.shtml

工具很强大，但只能打开由以下参数生成的GC log， -verbose:gc -Xloggc:gc.log,添加其他参数生成的gc.log无法打开。

GCViewer

http://www.tagtraum.com/gcviewer.html

这个工具用的挺多的，但只能在JDK1.5以下的版本中运行，1.6以后没有对应。

garbagecat

http://code.google.com/a/eclipselabs.org/p/garbagecat/wiki/Documentation

其它监控方法

Jvisualvm

Jvisualvm动态分析jvm内存情况和gc情况，插件：visualGC

jvisualvm还可以heapdump出对应hprof文件（默认存放路径：监控的服务器 /tmp下），利用相关工具，比如HPjmeter可以对其进行分析

grep Full gc.log粗略观察FullGC发生频率

jstat –gcutil [pid] [intervel] [count]

jmap

jmap -histo pid可以观测对象的个数和占用空间

jmap -heap pid可以观测jvm配置参数，堆内存各区使用情况

jprofiler,jmap dump出来用MAT分析

如果要分析的dump文件很大的话，就需要很多内存，很容易crash。

所以在启动时，我们应该加上一些参数： Java –Xms512M –Xmx1024M –Xss8M

参考资料：

探秘Java虚拟机——内存管理与垃圾回收http://sunbean.blog.51cto.com/972509/768034

Tomcat中JVM内存溢出及合理配置

Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个Java虚拟机。Tomcat的内存溢出本质就是JVM内存溢出，所以在本文开始时，应该先对Java JVM有关内存方面的知识进行详细介绍。

一、Java JVM内存介绍

JVM管理两种类型的内存，堆和非堆。按照官方的说法：“Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在 Java 虚拟机启动时创建的。”“在JVM中堆之外的内存称为非堆内存(Non-heap memory)”。简单来说堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给自己用的，所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每个类结构(如运行时常数池、字段和方法数据)以及方法和构造方法的代码都在非堆内存中，它和堆不同，运行期内GC不会释放其空间。

(1). 堆内存分配
JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。默认空余堆内存小于 40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、 -Xmx相等以避免在每次GC 后调整堆的大小。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行堆内存设置，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值，建议堆的最大值设置为可用内存的最大值的80%。

初始化堆的大小是JVM在启动时向系统申请的内存的大小。一般而言，这个参数不重要。但是有的应用程序在大负载的情况下会急剧地占用更多的内存，此时这个参数就是显得非常重要，如果JVM启动时设置使用的内存比较小而在这种情况下有许多对象进行初始化，JVM就必须重复地增加内存来满足使用。由于这种原因，我们一般把-Xms和-Xmx设为一样大，而堆的最大值受限于系统使用的物理内存。一般使用数据量较大的应用程序会使用持久对象，内存使用有可能迅速地增长。当应用程序需要的内存超出堆的最大值时JVM就会提示内存溢出，并且导致应用服务崩溃。所以，如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。

(2). 非堆内存分配
也叫永久保存的区域，用于存放Class和Meta信息,Class在被Load的时候被放入该区域。它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理。JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。 GC不会对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。

(3). JVM内存限制(最大值)
首先JVM内存限制于实际的最大物理内存（废话！，呵呵），假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，这个限制一般是2GB-3GB（一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了。

二、三种内存溢出异常介绍

1. OutOfMemoryError： Java heap space 堆溢出

内存溢出主要存在问题就是出现在这个情况中。当在JVM中如果98％的时间是用于GC且可用的 Heap size 不足2％的时候将抛出此异常信息。

2. OutOfMemoryError： PermGen space 非堆溢出（永久保存区域溢出）

这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。

3. OutOfMemoryError： unable to create new native thread. 无法创建新的线程

这种现象比较少见，也比较奇怪，主要是和jvm与系统内存的比例有关。这种怪事是因为JVM已经被系统分配了大量的内存（比如1.5G），并且它至少要占用可用内存的一半。

三、Java JVM内存配置

1. JVM内存分配设置的参数有四个

-Xmx Java Heap最大值，默认值为物理内存的1/4；

-Xms Java Heap初始值，Server端JVM最好将-Xms和-Xmx设为相同值，开发测试机JVM可以保留默认值；

-Xmn Java Heap Young区大小，不熟悉最好保留默认值；

-Xss 每个线程的Stack大小，不熟悉最好保留默认值；

-XX:PermSize：设定内存的永久保存区域；

-XX:MaxPermSize：设定最大内存的永久保存区域；

-XX:PermSize：设定内存的永久保存区域；

-XX:NewSize：设置JVM堆的‘新生代’的默认大小；

-XX:MaxNewSize：设置JVM堆的‘新生代’的最大大小；

2. 如何设置JVM的内存分配

（1）当在命令提示符下启动并使用JVM时（只对当前运行的类Test生效）：

java -Xmx128m -Xms64m -Xmn32m -Xss16m Test

（2）当在集成开发环境下（如eclipse）启动并使用JVM时：

a. 在eclipse根目录下打开eclipse.ini，默认内容为（这里设置的是运行当前开发工具的JVM内存分配）： -vmargs -Xms40m -Xmx256m -vmargs表示以下为虚拟机设置参数，可修改其中的参数值，也可添加-Xmn，-Xss，另外，eclipse.ini内还可以设置非堆内存，如：-XX:PermSize=56m，-XX:MaxPermSize=128m。

b. 打开eclipse－窗口－首选项－Java－已安装的JRE（对在当前开发环境中运行的java程序皆生效）编辑当前使用的JRE，在缺省VM参数中输入：-Xmx128m -Xms64m -Xmn32m –Xss16m。

c. 打开eclipse－运行－运行－Java应用程序（只对所设置的java类生效）选定需设置内存分配的类－自变量，在VM自变量中输入：-Xmx128m -Xms64m -Xmn32m -Xss16m 注：如果在同一开发环境中同时进行了b和c设置，则b设置生效，c设置无效，如：开发环境的设置为：-Xmx256m，而类Test的设置为：-Xmx128m -Xms64m，则运行Test时生效的设置为： -Xmx256m -Xms64m。

（3）当在服务器环境下（如Tomcat）启动并使用JVM时（对当前服务器环境下所以Java程序生效）：

a. 设置环境变量：变量名：CATALINA_OPTS 变量值：-Xmx128m -Xms64m -Xmn32m -Xss16m。

b. 打开Tomcat根目录下的bin文件夹，编辑catalina.bat，将其中的%CATALINA_OPTS%（共有四处）替换为：-Xmx128m -Xms64m -Xmn32m -Xss16m。

c. 若没有catalina.bat，只有tomcat.exe,tomcat6w.exe;则可以在启动tomcat6w.exe 后右键配置--Java--java option 下面输入：

-Xmx256m –Xms64m

也可以找到注册表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\TomcatService Manager\Tomcat6\Parameters\JavaOptions原值为 -Dcatalina.home="C:\ApacheGroup\Tomcat 6.0" -Djava.endorsed.dirs="C:\ApacheGroup\Tomcat 6.0\common\endorsed" -Xrs 加入 -Xms300m -Xmx350m （我的是加入-Xmx350m，tomcat才能启动，加入-Xms300m -Xmx350m反而tomcat都不能启动）重起tomcat服务,设置生效。

3. 查看JVM内存信息

Runtime.getRuntime().maxMemory(); //最大可用内存，对应-Xmx

Runtime.getRuntime().freeMemory(); //当前JVM空闲内存

Runtime.getRuntime().totalMemory(); //当前JVM占用的内存总数，其值相当于当前JVM已使用的内存及freeMemory()的总和

关于maxMemory()，freeMemory()和totalMemory()：maxMemory()为JVM的最大可用内存，可通过-Xmx设置，默认值为物理内存的1/4，设置不能高于计算机物理内存； totalMemory()为当前JVM占用的内存总数，其值相当于当前JVM已使用的内存及freeMemory()的总和，会随着JVM使用内存的增加而增加； freeMemory()为当前JVM空闲内存，因为JVM只有在需要内存时才占用物理内存使用，所以freeMemory()的值一般情况下都很小，而JVM实际可用内存并不等于freeMemory()，而应该等于maxMemory()-totalMemory()+freeMemory()。

4. 实例，以下给出1G内存环境下java jvm 的参数设置参考

JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "

大型的web工程，用tomcat默认分配的内存空间无法启动，如果不是在myeclipse中启动tomcat可以对tomcat这样设置：

TOMCAT_HOME\bin\catalina.bat 中添加这样一句话：

set JAVA_OPTS= -Xmx1024M -Xms512M -XX:MaxPermSize=256m

如果要在myeclipse中启动，上述的修改就不起作用了，可如下设置：

Myeclipse->preferences->myeclipse->servers->tomcat->tomcat×.×->JDK面板中的

Optional Java VM arguments中添加：-Xmx1024M -Xms512M -XX:MaxPermSize=256m

对于单独的.class，可以用下面的方法对Test运行时的jvm内存进行设置。 java -Xms64m -Xmx256m Test -Xms是设置内存初始化的大小 -Xmx是设置最大能够使用内存的大小。

四、JVM内存配置与GC

需要考虑的是Java提供的垃圾回收机制。JVM的堆大小决定了JVM花费在收集垃圾上的时间和频度。收集垃圾可以接受的速度与应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。如果堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。如果你把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为保证最好的性能，要把堆的大小设大，保证垃圾收集不在整个基准测试的过程中出现。如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过 3-5 秒。如果垃圾收集成为瓶颈，那么需要指定堆的大小，检查垃圾收集的详细输出，研究垃圾收集参数对性能的影响。一般说来，你应该使用物理内存的 80% 作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。

Java Heap分为3个区：

1.Young 2.Old 3.Permanent。Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。

JVM有2个GC线程：
第一个线程负责回收Heap的Young区；
第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区，Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。

为什么一些程序频繁发生GC？有如下原因：

程序内调用了System.gc()或Runtime.gc()。
一些中间件软件调用自己的GC方法，此时需要设置参数禁止这些GC。
Java的Heap太小，一般默认的Heap值都很小。
频繁实例化对象，Release对象此时尽量保存并重用对象，例如使用StringBuffer()和String()。

如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态许多Server端的Java程序每次GC后最好能有65%的剩余空间。

经验之谈：
1．Server端JVM最好将-Xms和-Xmx设为相同值。为了优化GC，最好让-Xmn值约等于-Xmx的1/3。
2．一个GUI程序最好是每10到20秒间运行一次GC，每次在半秒之内完成。

注意：
1．增加Heap的大小虽然会降低GC的频率，但也增加了每次GC的时间。并且GC运行时，所有的用户线程将暂停，也就是GC期间，Java应用程序不做任何工作。
2．Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，因为Java为其他任务分配内存，例如每个线程的Stack等。

原文地址：http://blog.51cto.com/235571/2132968

时间： 2024-10-13 16:29:55

6月27日任务2

4 jvm性能调优监控工具jps/jstack/jmap/jhat/jstat

jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令

5 gvm gc 相关

JVM gc参数设置与分析

Tomcat中JVM内存溢出及合理配置

6月27日任务2的相关文章

微软苏州校招笔试 12月27日

2014年5月27日中国大陆封锁Google事件解决的方法

全国身份证前6位地区编码归属地(2016年06月27日）共6724条

中级学员：2015年10月27日作业

2014年4月27日后悔书

4月27日下午学习日志

4月27日作业

4月27日上午学习日志

老男孩教育每日一题-2017年4月27日-如何正确清理MySQL binlog?

10月27日全球域名商解析新增量TOP20：爱名网第三