Eclipse Memory Analyzer（MAT）是一个图形化的Java堆分析工具，速度快且特性丰富，可以用于取代JDK自带的堆Dump浏览器（jhat）。使用MAT，你可以快速分析包含上亿对象的生产环境Dump文件，快速计算某种对象导致的内存占用量，进而评估内存泄漏风险。

你可以将MAT安装为独立运行的RCP应用，也可以作为插件安装到现有的Eclipse中。

jhat不是本文的主题，这里做一个简单的介绍。

这是JVM自带的堆Dump分析工具，执行如下命令即可使用：

jhat a.map  # a.map为Dump文件路径

jhat默认在7000端口暴露HTTP服务，你可以通过浏览器进行以下查询：

下面是一段急剧消耗内存的示例代码：

package com.dangdang.digital.test;

import org.apache.commons.lang.math.RandomUtils;

import java.util.concurrent.TimeUnit;

public class BusyApplication {

    public static void main( String[] args ) {
        new MemoryPredator( Integer.parseInt( args[0] ), Integer.parseInt( args[1] ) ).start();
    }

}

class MemoryPredator extends Thread {

    private final int consumeInterval;

    private int retainTime;

    public MemoryPredator( int consumeInterval, int retainTime ) {
        this.consumeInterval = consumeInterval;
        this.retainTime = retainTime;
    }

    @Override
    public void run() {
        for ( ; ; ) {
            consumeMemory( retainTime );
            try {
                TimeUnit.MILLISECONDS.sleep( consumeInterval );
            } catch ( InterruptedException e ) {
            }
        }
    }

    private void consumeMemory( final int retainTime ) {
        new MemoryPreyThread( retainTime ).start();
    }

}

class MemoryPreyThread extends Thread {

    private final int retainTime;

    public MemoryPreyThread( int retainTime ) {
        this.retainTime = retainTime;
    }

    @Override
    public void run() {
        int n = ( RandomUtils.nextInt( 100 ) + 1 );
        Object bigObj = createBigObject( n );
        System.out.println( String.format( "%d MB consumed", n ) );
        try {
            TimeUnit.MILLISECONDS.sleep( retainTime );
        } catch ( InterruptedException e ) {
        }
    }

    private Object createBigObject( int n ) {
        Object big = new byte[n * 1024 * 1024];
        return big;
    }
}

让上述程序执行一段时间（应用程序参数使用500 7000），然后使用下面的命令获取堆Dump：

# 只Dump可达对象，使用二进制格式，输出为bzapp.hprof
jmap -dump:live,format=b,file=bzapp.hprof  `jps | grep BusyApplication | cut -d' ' -f1`

通过jhat开启服务后，打开浏览器，首先看到的是堆中包含的类的列表（不包含平台类）：

All Classes (excluding platform)

Package com.dangdang.digital.test
class com.dangdang.digital.test.BusyApplication [0xc0005048]
class com.dangdang.digital.test.MemoryPredator [0xc0004ff0]
class com.dangdang.digital.test.MemoryPreyThread [0xc0004f98]

Package com.jarego.jayatana
class com.jarego.jayatana.Agent [0xc0005200]

Package org.apache.commons.lang.math
class org.apache.commons.lang.math.JVMRandom [0xc0004e60]
class org.apache.commons.lang.math.RandomUtils [0xc0004f00]

点击界面下方的Show heap histogram连接，可以看到Shallow size最大的类型：

Class                                    Instance Count        Total Size

class [B                                 1063                  788662183
class [I                                 512                   6789172
class [C                                 2552                  349224
class java.lang.Class                    566                   54336
class [Ljava.lang.Object;                467                   48496
class [S                                 770                   44518
class java.lang.String                   2494                  39904
class java.net.URL                       346                   30448
class [Ljava.util.WeakHashMap$Entry;     156                   22464
class java.util.HashMap$Entry            771                   21588

可以看到byte[]类型，即[B，占用绝大部分内存，接近800MB。

点击class [B上的链接，进入byte[]类型的主页面“Class 0xc009a858”，后面的是类对象的内存地址，和Dump分析关系不大。留意“References to this object”这一段内容：

[B@0xbb0b6e18 (240 bytes) : ??
[B@0xc00bad20 (30 bytes) : ??
[B@0xbae503c0 (29 bytes) : ??
[B@0xbb091708 (115 bytes) : ??
[B@0xbb057350 (29 bytes) : ??

... 

[B@0xc87c6368 (15728656 bytes) : ??       # 大对象

任何类型的示例，都会持有该类型的Class对象的引用，byte[]也不例外。所有存活的byte[]对象因此列于“References to this object”中。我们需要关心的通常（取决于应用场景）是大对象，简单的滚动页面，留意那些更长的行，就可以定位到大的byte[]了。

可以看到对象[B@0xc87c6368占据了15M的内存空间，点击其上的链接，进入[B@0xc87c6368对象的主页面。在页面的下方，可以看到Other Queries - Reference Chains from Rootset - Exclude weak refs，点击后，可以查看从GC Root到此对象的引用链页面：

References to [B@0xc87c6368 (15728656 bytes)

Java Local References

Java Local Reference (from com.dangdang.digital.test.MemoryPreyThread@0xc4ec6208) : # 这是GCRoot

--> [B@0xc87c6368 (15728656 bytes)

至此，我们可以大概判定，引发内存问题的代码，位于类MemoryPreyThread中。

点击菜单项 File ⇨  Open Heap Dump ...，看到如下界面：

上半部分显示当前正在分析的对象的基本信息，以上面的截图为例：

下半部分包括4个选项卡：

1. Statics：此对象的类变量列表
2. Attributes：此对象的实例变量列表
3. Class Hierarchy：类层次图
4. Value：对象的值

此面板使用饼图显示Retained Size最大的对象，并列出其导致的内存驻留的尺寸。这些对象往往就是问题所在。

饼图上方的按钮区、和饼图下方的Actions/Reports/Step By Step，功能是对应的。

其中Actions包括：

1. Histogram：类似jhat的Histogram类似，但是支持统计Retained Size，支持排序
2. Dominator Tree：显示那些导致内存驻留最严重的对象，按对象导致驻留的比例，降序排列。可以展开这些对象的引用链
3. Top Consumers：以饼图、列表方式显示导致内存驻留最严重的对象、类、类加载器、包
4. Duplicate Classes：显示不同类加载器重复加载的类

其中Reports包括：

1. Leak Suspects：可以的内存泄漏报告，更加细粒度的、辅助人工分析的报告

使用jhat，我们就可以获取堆Dump中的全部信息了。 但是其UI非常简陋，缺乏排序、统计类功能，这些功能正是MAT能提供的。下面我们使用MAT来分析上一章的示例应用。

打开Dump后，在Overview面板的饼图上，可以立即看到所有大内存驻留都是由com.dangdang.digital.test.MemoryPreyThread类型的对象所引发。

单击任何一个饼图切片，点击菜单List Objects ⇨ With Outgoing References，可以看到对象引用的哪些对象的Shallow Size较大。这些对象就是内存驻留的根源：

很明显， MemoryPreyThread所引用的、byte[]类型的局部变量，其Shallow Size占据了全部内存份额。注意：如果上级对象的Outgoing引用特别多，则问题所在的子级对象可能看不到，这种情况下可以点击Retained Heap列排序或者手工展开。

对于像示例应用这样简单的代码，分析到这里就直接能定位到问题代码所在行号了。生产环境中的情况要复杂的多，单纯基于堆内存Dump进行静态分析不一定能奏效，需要结合线程栈Dump，甚至是剖析工具（JMC、JProfiler等）录制的内存分配历史。

概要情况如下图：

某个线程引用了接近6G的数据。从线程名字上来看，它是一个普通的工作线程，持有的6G内存应该是某种临时性对象。

分析此线程的Outgoing引用，排序Retained Heap列，将大内存条目显示出来：

可以看到，内存由一个局部变量（<Java Local>）导致。需要注意，局部变量的GC Root都是当前执行线程。出现问题的变量引用一个ArrayList对象，进一步展开可以猜测到此对象是数据库查询的结果集：

可以看到，此ArrayList的元素多达1000万。很可能是错误的SQL语句把大量行甚至整个表都读取过来，一下子把JVM内存撑爆了。

展开一个ByteArrayRow，查看行中的元素，进一步定位到所操作的表。配合JMC查看Hot Methods，定位到了存在问题的方法。

线上环境某服务，因为内存溢出、连续FGC被监控进程杀死，我们获得的堆Dump，内存占用总计1.7GB，Netty 3.x中的类NioClientSocketPipelineSink导致了绝大部分的内存驻留。

点击饼图中最大的切片NioClientSocketPipelineSink进行分析，打开菜单项List Objects ⇨ With Incoming References，展开：

可以看到NioClientSocketPipelineSink是Netty处理管线（Pipeline）的一部分。在很多框架中，管线常常和SRC、SINK等术语一起出现，SRC常常表示管线的输入、SINK则表示输出。

一个全局性的ChannelFactory、大量DefaultChannelPipeline通过sink属性引用了NioClientSocketPipelineSink。这些DefaultChannelPipeline应该是某种一次性对象，不熟悉代码的话只能猜测到这个程度，可以考虑通过JMC来录制对象分配的调用栈，来证实这种猜测。

那么，谁创建了这些DefaultChannelPipeline呢？从上面的截图中可以看到Dubbo的NettyClient间接引用了NioClientSocketPipelineSink，再随机抽取几个DefaultChannelPipeline展开：

可以看到来自Dubbo的NettyClient通过channel ⇨ pipeline ⇨ sink 引用了DefaultChannelPipeline。com.alibaba.dubbo上面引用链上唯一的非Netty包，我们有理由猜测Dubbo和内存溢出有关。

我们可以看一下相关对象的计数。对于希望统计数量的对象，在调用链上点选它，左下面板切换到Class Hierarchy，在类名上右击，选择List Object  ⇨ With Incoming References：

由于类的每个对象都会引用类对象，因此展开右侧窗口的根节点，即可知晓对象的大概数量。在本例中，DefaultChannelPipeline、NioClientSocketChannel的数量大概是130万，NettyClient的数量是33。

MAT的支配树功能，可以帮助你追踪实际（Shallow）消耗内存的对象：

可以看到，Netty内部的某种链表结构（LinkedTransferQueue）的每个元素的RegisterTask对象占用了1KB的内存，但是链表长度非常大，因此这个链表消耗了大量的内存。

从名字LinkedTransferQueue可以猜测，这是Netty用来存储待处理的网络数据的。

从MAT分析的结果来看，NioClientSocketPipelineSink的内部类Boss的实例变量registerTaskQueue，占据了高达1.64GB的内存。我们来看一下这个类是做什么的：

// 代码中不相关的部分做了删减
class NioClientSocketPipelineSink extends AbstractChannelSink {

    final Executor bossExecutor;

    private final Boss[] bosses;
    private final NioWorker[] workers;

    private final AtomicInteger bossIndex = new AtomicInteger();
    private final AtomicInteger workerIndex = new AtomicInteger();

    // 这是外部能影响队列registerTaskQueue的唯一入口
    public void eventSunk( ChannelPipeline pipeline, ChannelEvent e) throws Exception {
        if (e instanceof ChannelStateEvent) {

            ChannelState state = event.getState();
            Object value = event.getValue();

            switch (state) {
            case CONNECTED:
                if (value != null) {
                    // 连接到客户端通道
                    connect(channel, future, (SocketAddress) value);
                } else {
                    channel.worker.close(channel, future);
                }
                break;
        } else if (e instanceof MessageEvent) {}
    }


    private void connect(  final NioClientSocketChannel channel, final ChannelFuture cf, SocketAddress remoteAddress) {
        try {
            if (channel.socket.connect(remoteAddress)) {
                channel.worker.register(channel, cf);
            } else {
                // 通道是非阻塞模式，因此会走到这个分支
                nextBoss().register(channel);
            }

        } catch (Throwable t) {}
    }
    Boss nextBoss() {
        return bosses[Math.abs( bossIndex.getAndIncrement() % bosses.length)];
    }


    private final class Boss implements Runnable {

        private final AtomicBoolean wakenUp = new AtomicBoolean();
        private final Object startStopLock = new Object();
        private final Queue<Runnable> registerTaskQueue = new LinkedTransferQueue<Runnable>();

        // 这个方法直接导致registerTaskQueue增大
        void register(NioClientSocketChannel channel) {
            Runnable registerTask = new RegisterTask(this, channel);

            synchronized (startStopLock) {
                // 如果尚未启动，则使用Executor启动Client Boss线程
                // 每当有新的连接请求到达，都会尝试启动Client Boss线程
                if (!started) {
                    DeadLockProofWorker.start(
                                bossExecutor,
                                new ThreadRenamingRunnable(
                                        this, "New I/O client boss #" + id + '-' + subId));
                }
                // 添加一个RegisterTask
                boolean offered = registerTaskQueue.offer(registerTask);
            }

            if (wakenUp.compareAndSet(false, true)) {
                // 唤醒选择器
                selector.wakeup();
            }
        }

        public void run() {
            Selector selector = this.selector;
            long lastConnectTimeoutCheckTimeNanos = System.nanoTime();
            for (;;) {
                wakenUp.set(false);

                try {
                    // 最多阻塞500ms
                    int selectedKeyCount = selector.select(500);
                    if (wakenUp.get()) {
                        selector.wakeup();
                    }
                    // 消费registerTaskQueue队列
                    processRegisterTaskQueue();

                    
                    if (selector.keys().isEmpty()) {
                        if (shutdown ||
                            bossExecutor instanceof ExecutorService && ((ExecutorService) bossExecutor).isShutdown()) {

                            synchronized (startStopLock) {
                                if (registerTaskQueue.isEmpty() && selector.keys().isEmpty()) {
                                    // 标记Client Boss线程为停止状态，下次再有连接请求到达，会再次启动
                                    started = false;
                                    try {
                                        selector.close();
                                    } catch (IOException e) {
                                        logger.warn(
                                                "Failed to close a selector.", e);
                                    } finally {
                                        this.selector = null;
                                    }
                                    // 退出条件
                                    break;
                                } else {
                                    shutdown = false;
                                }
                            }
                        } else {
                            shutdown = true;
                        }
                    } else {
                        shutdown = false;
                    }

                } catch (Throwable t) {}
            }
        }

        private void processRegisterTaskQueue() {
            for (;;) {
                final Runnable task = registerTaskQueue.poll();
                if (task == null) {
                    break;
                }

                task.run();
            }
        }

    private static final class RegisterTask implements Runnable {

        RegisterTask(Boss boss, NioClientSocketChannel channel) {
            this.boss = boss;
            this.channel = channel;
        }

        public void run() {
            try {
                // 在指定的选择器上注册通道的事件
                channel.socket.register( boss.selector, SelectionKey.OP_CONNECT, channel);
            } catch (ClosedChannelException e) {
                channel.worker.close(channel, succeededFuture(channel));
            }

            int connectTimeout = channel.getConfig().getConnectTimeoutMillis();
            if (connectTimeout > 0) {
                channel.connectDeadlineNanos = System.nanoTime() + connectTimeout * 1000000L;
            }
        }
    }
}

可以看到：

1. 每当有新的连接请求时，都会调用Boss.register，从而唤醒Boss.run线程
2. 一旦Boss.run线程线程启动，它就会消费掉所有堆积的registerTaskQueue元素

也就是说，正常情况下，registerTaskQueue队列不应该出现堆积的。由于发现问题时没有开启Dubbo或Netty的日志，准备等待下次问题重现后继续深入分析。

The post 使用Eclipse Memory Analyzer分析JVM堆Dump appeared first on 绿色记忆.

Oracle  Java Mission Control（以下称JMC）是一个集成到JVM（jdk7u40+）的性能剖析和诊断工具，相比起JProfiler之类的性能剖析工具，JMC更加简单易用，界面友好。

JMC使用了JVM内部特定的基于事件的接口，不同于一般性能剖析工具使用JVMPI/JVMTI方式实现。因此JMC几乎不会给应用造成额外的压力，可以用在负载很高的生产环境中：

1. JFR在默认设置continuous下运行几乎对性能没有影响
2. JFR在默认设置profiling下运行通常造成小于2%的性能下降

在JDK 7 Update 40及其以后的版本中已经集成了JMC（%JDK_HOME%\bin\jmc.exe），打开此程序，会发现它是一个典型的Eclipse RCP应用。本文简单的介绍如何使用JMC来监控、记录JVM的运行过程。

-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=7777
-Dcom.sun.management.jmxremote
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder

如果要在目标JVM上启动持续不断的黑匣子记录，并在JVM正常退出时Dump记录为文件，可以参考下面的脚本设置JVM参数：

for /f "tokens=1-3 delims=/ " %%a in ('date /t') do (set md=%%a-%%b-%%c)
for /f "tokens=1-3 delims=/:." %%a in ("%TIME%") do (set mt=%%a%%b%%c)
set CUR_TIME=%md%-%mt%

rem 启用黑匣子默认记录行为。官方文档注明dumponexitpath支持目录，但我在7u71版本下测试失败
set JAVA_OPTS=%JAVA_OPTS% -XX:FlightRecorderOptions=defaultrecording=true,disk=true,dumponexit=true,dumponexitpath=%LOG_DIR%\jfr\dump-on-exit-%CUR_TIME%.jfr,maxage=3600s,settings=%JRE_HOME%\lib\jfr\profile.jfc

配置并重启目标JVM后，打开JMC，点击 File - Connect... - Create New connection，参考下图设置，完毕后点击Test connection确认可以连通，最后点击Finish结束配置。

在左侧窗格JVM Browser视图中，双击刚刚创建的JMC连接，点击MBean Server，即可在右侧主窗体查看实时的JVM状态信息，供6个选项卡，下面依次描述。

包含JVM概要性的实时图表，包含3个面板：

以树形结构显示目标JVM支持的所有MBean列表和属性、操作集。

包含若干预定义的触发器，可以在特定条件下，执行预定义的动作。支持的触发器包括：

此外，任何MBean属性均可以作为触发器使用，中间件（例如Tomcat、Weblogic、ActiveMQ）都有自己的扩展。 双击触发器后，右侧即显示规则详情（Rule Details），可以定义触发的阈值（到达时，或者从异常值恢复时）、执行的动作，可用的动作包括：

所谓LiveSet，是指在一次垃圾回收之后，堆内存的占用比率，取值在0-1之间。

如果GC后，可用的内存空间不足，则LiveSet接近100%，这预示可能存在OOM风险。在生产环境下，我们可以监控LiveSet，并在其过大时，把堆内存映像Dump出来供后续分析。

触发器配置示例：

其中Condition面板：

1. Current Value为指标的当前值，当发生GC后，自动刷新
2. Max trigger value为触发器激活时的指标值
3. Sustained period，指标必须到达Max trigger value至少多长时间，触发器才可能激活
4. Limit period，连续两次激活触发器的最小间隔时间

其中Action面板：

1. Only live，如果勾选，仅仅GCRoot可达的对象才被Dump出来
2. hprof路径为服务器的路径

其中Constraints面板：可以指定此触发器在什么日期、什么时间段启用。

要分析内存映像，你可以使用如下命令启动一个Web UI：

jhat -port 7770 -J-Xmx4G default.hprof

显示JVM和系统的概要信息，包含3个面板：

1. 系统信息：例如OS类型、硬件架构、系统内存、JVM的PID、JVM版本、Classpath、JVM启动时间、JVM参数（Java Options）
2. JVM统计：例如已加载的类数量、已运行时间
3. 系统属性：显示JVM的系统属性

显示JVM内存占用情况，分为上下两个面板。

显示JVM线程活动情况，分为三个面板。

正如民航的黑匣子一样，JMC的这个功能，可以用于事后分析系统性能低下，甚至崩溃的原因。JMC支持两种方式来启动黑匣子记录：通过触发器自动启动， 或者在左侧面板，双击Flight Recorder，手工启动。手工启动可以参考下图设置：

其中：Time fixed recording表示记录定长时间，时间到达后，自动停止记录；Continuous recording表示进行持续不断的记录，直到JVM退出或者接收到停止指令，这种记录方式下可以随时进行dump操作。

虽然黑匣子在JVM本地记录数据，但不在Java堆中记录，因此它并不会影响内存特性和垃圾收集。

黑匣子录制完成后，会在你选择的目录中生成一个.jfr文件，该文件包含录制期间JVM中发生的各种事件。

黑匣子通过JVM内部API来收集数据，并存放在一个线程本地（thread-local）的缓冲中，并最终刷入全局内存缓冲（global in-memory buffer），内存缓冲中的数据，会被刷入磁盘，磁盘文件时经过压缩的。每个记录数据块，要么在内存中，要么在磁盘中，这意味着——进程被停止或者宕机时，部分数据会丢失，JVM崩溃会也可能导致一部分数据丢失。

可以配置黑匣子不使用磁盘空间，这种场景下，全局内存缓冲被循环使用，旧的数据自动丢弃。

在JMC界面上，点击 Windows - Flight Recording Template Manager，看到类似如下界面。可以导入、导出、编辑JFR的设置文件。

我们可以导入%JDK_HOME%\jre\lib\jfr下的两个自带模板：default.jfc（Continuous）、profile.jfc（Profiling）。这两个模板的对比如下：

利用诊断命令，可以通过脚本控制黑匣子的行为，命令的示例如下：

rem 获取进程号为5361的JVM关于JFR.start命令的帮助
jcmd 5361 help JFR.start

rem 检查进程的JFR运行状态
jcmd 7648 JFR.check
rem 输出如下。注意recording=0表示正在运行的记录的标识符，后续操作需要用到这个标识符
rem 7648:
rem Recording: recording=0 name="HotSpot default" maxage=1h (running)

rem 启动一个15分钟的黑匣子记录，延迟5分钟启动，使用JDK自带的默认设置（default.jfc），保存Dump文件到D盘
jcmd 7648 JFR.start name=SampleRcd delay=300 duration=900s filename=D:\temp\SampleRcd.jfr 
     \ settings=D:\JavaEE\jdk\x64\jre\lib\jfr\default.jfc

rem 相对路径取决于目标JVM
jcmd 1234 JFR.start delay=0s duration=${jfr_du}s name=$name filename=$PWD/$name.jfr settings=profile

rem 下面的脚本，可以用于定期进行记录，按记录时间保存为不同的文件
setlocal
set DUMP_DIR=D:\temp
set SERVICE_NAME=Tomcat7
set JAVA_HOME=D:\JavaEE\jdk\x64\1.7
pushd %JAVA_HOME%\bin
for /f "tokens=1-3 delims=/ " %%a in ('date /t') do (set md=%%a-%%b-%%c)
for /f "tokens=1-3 delims=/:." %%a in ("%TIME%") do (set mt=%%a%%b%%c)
set CUR_TIME=%md%-%mt%
for /F "tokens=1,3" %%a in ('sc queryex %SERVICE_NAME%') do (
    if "%%a" == "PID" set "JPID=%%b"
)

rem 启动飞行记录，如果目标JVM是以SYSTEM身份启动的NT Service，可以使用PSTools发起jcmd命令，否则会报错：insufficient memory or insufficient privileges to attach
rem psexec -s jcmd %JPID% JFR.start ...
jcmd %JPID% JFR.start name=rcd-%CUR_TIME% duration=900s compress=true filename=%DUMP_DIR%\rcd-%CUR_TIME%.jfr settings=%JAVA_HOME%\jre\lib\jfr\profile.jfc
popd
endlocal

rem 导出JFR的Dump文件
rem 如果目标JVM正在在运行持续不断的黑匣子记录，使用该命令，再结合定时任务机制，可以定期保存黑匣子记录的Dump文件
jcmd 7648 JFR.dump recording=0 filename=F:\temp\dump.jfr

打开黑匣子记录的.jfr文件，即可看到类似下面的界面：左侧是记录的不同视图，可以点击切换；右侧主面板，顶部是事件的时间轴，拖动滑块，可以改变聚焦的时间范围（勾选右边的同步选择可以在切换视图时保持聚集范围），底部有若干选项卡。

下面，按照视图分别描述。

包含4个选项卡：

可以看到聚焦时间范围内的实时仪表（堆占用、CPU占用、GC停顿时间），以及CPU、堆使用情况的曲线图。

可以看到JVM的一些基本信息，包括启动时间、JVM参数等。

可以看到JVM的系统属性列表

可以显示记录的事件的列表

包含6个选项卡

Memory Usage：可以显示聚焦时间范围内OS总内存、OS已使用内存、提交的堆、使用的堆的大小曲线图。

GC Configuration：显示简单的GC配置

GC Statistics：显示简单的GC统计，包括垃圾回收次数、停顿时间

上面的面板，包含4个选项卡：

Heap：堆的使用情况曲线，红色小柱形显示了GC停顿的持续时间（刻度在右边）

Reference Objects：包含软引用、弱引用、幻引用、一般引用的数量变化区域图

Failed Promotions：失败的晋升列表，所谓晋升是指：年轻代对象向年老代转移的GC动作，包含对象个数和大小等信息

Failed Evacuations：

下面的面板，左侧显示历次GC的列表，右侧显示单次GC的详细信息，如下：

General：显示GC类型、触发原因、ID、开始结束时间、暂停时间

GC Phase：GC每个步骤的开始和持续时间

Reference Objects：本次GC涉及的各类引用的数量

Heap：堆在GC前后的大小对比

Perm Gen：永久代在GC前后的大小对比

显示各代、各次GC所消耗的时间

显示GC的详细配置，包括GC基本配置、堆的配置、年轻代的配置

显示聚焦时间范围内的内存分配统计信息

General：在线程本地分配缓冲（TLAB）内、外（即Eden区域）中分配的对象个数、内存大小。面板下部是内存分配大小按时间的柱形图

Allocation in new TLAB：在TLAB中分配的内存，按对象类型、或者按执行分配的线程的占比饼图；Allocation Profile可以剖析分配内存热点所在的调用栈

Allocation outside TLAB：在Eden区域的内存分配情况，包含的子选项卡同上

示例：

在Allocation By Class选项卡中：

1. 上面板Allocation Pressure，按对象类型，显示内存占用最大的对象
2. 下面板Stack Trace，选中上面板的某个对象类型后，在此显示分配对象的调用栈。第一行为直接分配对象的代码

显示对象数量和内存占用的统计信息，包含上下两部分

上面的面板：显示占有堆内存百分比大于0.5%的类型的列表

下面的面板：显示增长数量最快的类型的列表

包含6个选项卡：

显示占用CPU时间最多的代码，分为上下两部分

上面的面板：显示CPU时间占用最多的包，包括列表和饼图

下面的面板：显示CPU占用最多的类，按占比降序排列

显示热点方法（CPU占用时间最多），按占比降序排列，点击左侧小箭头可以向下钻取（找到哪些代码调用了这个方法导致的热点）

类似于热点方法选项卡，但是会显示所有热点方法的完整调用栈

包含3个选项卡，显示异常（包括错误）的统计信息

Overview：显示异常和错误的总数、最频繁发生异常的调用栈

Exceptions、Error：单独显示异常或者错误的总数、频繁调用栈，注意，异常默认是不记录的

显示即时编译的次数、编译大小、失败的日志

显示按时间的类加载、卸载的数量曲线图

分为上下两部分：

上面的面板：显示OS、JVM的CPU占用率的按时间统计的区域图

下面的面板：显示守护线程、活动线程数量的曲线图

显示CPU占用最多的线程，及选中线程的热点方法，分为上下两部分

上面的面板：显示CPU占用最多的线程，按占比降序排列

下面的面板：显示上面板选中线程的热点方法、调用栈 

显示因为锁争用导致的线程阻塞的统计信息，分为3个选项卡：

Top Blocking Locks：发生阻塞最多的监视器（锁）对象的列表，包含了锁定次数、最长时间

Top Blocked Threads：因为等待锁被阻塞时间最长的线程的列表

Top Blocking Threads：因为占用锁导致其他线程等待时间最长的线程的列表

显示因为：Java线程休眠、监视器等待、Socket读取、监视器阻塞等原因导致的线程执行延迟的情况，包括延迟信息的列表和饼图，已经导致延迟的线程调用栈。延迟相关的事件包括：Java Thread Park（Waiting）、Java Monitor Wait（等待被唤醒）、Java Monitor  Blocked（积极进入同步区被阻塞）等。

包含定时捕获的JVM中所有线程的瞬时调用栈镜像

Lock Instances：监视器对象的列表，包含锁定次数、总计持续时间

Trace Tree：选中监视器对象的锁定调用栈，每个调用栈锁定的次数

Top Threads：占用监视器次数最多的线程列表

分为两个选项卡

File Overview：

File Reads and Writes：显示按时间读写文件字节数的曲线

File Read、File Write：显示针对具体文件的读写字节数、次数的列表

Socket Overview：

Socket Read and Writes：显示按时间读写Socket字节数的曲线

Socket  Read、Socket Writes：显示针对具体目标主机、端口读写字节数、次数的列表

按文件、线程、事件统计文件读操作的列表，以及每个文件读取按时间的变化、线程调用栈

按文件、线程、事件统计文件写操作的列表，以及每个文件写入按时间的变化、线程调用栈

按目标主机、线程、事件统计文Socket读操作的列表，以及每个Socket读取按时间的变化、线程调用栈

按目标主机、线程、事件统计文Socket写操作的列表，以及每个Socket写入按时间的变化、线程调用栈

显示黑匣子记录的事件的相关信息，左侧面板Event Types可以过滤关注的事件类型。总体来说，事件可以分为三类：持续事件（duration，持续一段时间，例如GC事件）；瞬时事件（instant，立即发生和结束，例如内存溢出）；样本事件（sample，通过定期采样获取，例如栈dump）。

Producers：显示事件生产者的列表，以及制造事件的占比饼图

Event Types：显示各类型事件持续总时间、次数，占比饼图

显示每一个事件的记录，按时间排列，为每个事件显示：开始时间、结束时间、持续时间、产生事件的线程

以时间轴的形式展示事件历史

以列表形式展示各线程产生事件的数量、持续时间

按产生事件持续时间长短，降序排列相关的调用栈

可以按单个事件类型进行简单的统计分析，支持不同的分组方式，支持总数、平均数、次数等指标，选中单个统计结果，可以显示调用栈。

The post 使用Oracle Java Mission Control监控JVM运行状态 appeared first on 绿色记忆.

本文主要适用于HotSpot JVM的参数设置与调优。

#每250毫秒査询一次进程2764垃圾收集的状况，一共査询20次
jstat -gc 2764 250 20

jinfo -flag CMSInitiatingOccupancyFraction 1444 
#输出-XX：CMSInitiatingOccupancyFraction=85

jmap -dump:format=b,file=eclipse.dump 3500
#Dumping heap to ...
#Heap dump file created

# 显示进程5732的GC可达对象直方图
jmap -histo:live 5732

jcmd 0 help

# 打印JVM参数
jcmd 25464 VM.flags

# 打印所有系统属性
jcmd 25464 VM.system_properties

# Dump出线程栈
jcmd 25464 Thread.print

# Dump出堆
jcmd 25464 GC.heap_dump

# 强制GC
jcmd 25464 GC.run

# options：JVM参数
# class：main方法所在类
java [ options ] class [ arguments ]
# -jar 被调用的jar包路径
java [ options ] -jar file.jar [ arguments ]
#用于GUI
javaw [ options ] class [ arguments ]
javaw [ options ] -jar file.jar [ arguments ]

-XX:+PrintFlagsFinal
-XX:PrintFLSStatistics=1
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps
-XX:-TraceClassUnloading
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintTenuringDistribution
-Xloggc:%LOG_DIR%\gc.log

1. 响应时间优先：尽量大，直到接近最低响应时间的需求限制
2. 吞吐量优先：尽量大，最好到达Gbits

1. 响应时间优先：年老代默认CMS收集，需要考虑会话并发数、持续时间等因素，太小，造成碎片、高频回收、暂停并导致标记清除；太大，导致收集时间长。根据：CMS收集信息、次数、年轻代/年老代回收时间比率确定
2. 吞吐量优先：一般都是较大的年轻代、较小的年老代。由于并发大，年轻代对象多，所以要求尽快收集年轻代对象，年老代存放长期存活对象
3. 小堆引起的内存碎片问题：CMS算法不会对堆进行整理，导致碎片问题，配置 -XX:+UseCMSCompactAtFullCollection、-XX:CMSFullGCsBeforeCompaction来启用整理

7u9以后的版本，可以使用G1回收器，这是一个新型、综合的垃圾回收器。

可以使用类似如下方式启用：java -Xmx2G -Xms2G  -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:G1ReservePercent=20  -XX:ConcGCThreads=8

一般认为64bit虚拟机的性能低于32位，所有某些时候32bit虚拟机集群比一个大的64bit虚拟机更合适。

如果JVM内存配置很大，DUMP内存映像将是非常耗时的，这和磁盘写入速度有关系

对于年轻代来说，非常大的内存空间不会对性能造成显著影响；而对于年老代，除非使用CMS垃圾回收器（默认是吞吐量优先的Parallel Old），否则可能导致很长的GC停顿（30G以内的内存可能数十秒 ，更高的内存可能数分钟），这对于用户交互式程序是无法忍受的。

CMS对于大概小于4G的堆来说，其初始标记、重标记STW时间较短，对于频繁制造垃圾的大堆，则亦可能出现问题，当CMS的工作跟不上年老代被占满的步伐时，会导致STW的串行垃圾回收器被启用，在16G内存下，这可能导致30秒或者更多的停顿，尽早（年老代被占用百分比）启用CMS，可能在一定程度上减少STW出现几率。注意，越是多核心的处理器，越可能导致CMS停顿的问题，因为CMS只会使用一个核心。

G1垃圾回收器不能解决CMS的问题，它的吞吐量甚至低于CMS。

1. 对于G1垃圾回收器：避免使用 -Xmn 选项或 -XX:NewRatio 等其他相关选项显式设置年轻代大小，因为固定年轻代的大小会覆盖暂停时间目标
2. 让堆的最小、最大尺寸一致
3. 为新生代提供足够的空间，使大部分对象停留在新生代，同时，要避免老年代触发垃圾收集（保持有10-20%的空闲空间）
4. 让新生代对象生命周期尽量短，避免使其进入年老代
5. 避免短命的大对象，-XX:PretenureSizeThreshold设置直接进入年老代的阈值
6. 将需要大量内存的模块使用C++等手工管理内存的语言实现
7. 如果有海量内存，可以使用具有低延迟、无停顿GC的虚拟机，例如Azul，它的C4回收器具有这样的特征

CMS相关垃圾回收的可能原因有：

1. System.gc() 的调用
2. 老年代占比超过-XX:CMSInitiatingOccupancyFraction
3. 如果启用-XX:+CMSClassUnloadingEnabled，当永久代占比超过-XX:CMSInitiatingPermOccupancyFraction
4. 晋升失败（Promotion Failed）：YGC时，Survivor区放不下所有对象，而且老年代也放不下，原因不一定是老年代空间不足，也可能是老年代碎片引起
5. 并发模式失败（Concurrent Mode Failure ）：CMS的同时进行YGC，导致CMS完成前老年代空间不足（Full Promotion Guarantee Failure），此情况下会发生Full GC。可能需要调小新生代或者减小-XX:CMSInitiatingOccupancyFraction

'前缀时间戳，例如221810.102，表示JVM已经启动的秒数'
'时间times：user表示对于当前进程CPU消耗在user-mode的时间；sys表示对于当前进程CPU消耗在kernel-mode的时间；real表示物理时间的时间；'
'ParNew的年轻代垃圾收集（YGC），20024K为GC开始时的内存占用，497K为GC结束后的内存占用，39296K为总大小，0.0046067 为新生代局部收集消耗时间'
'后面的20024K->9715K(126720K)表示整个堆收集前后内存占用和总内存，最后的Times显示GC过程中的总时间消耗'
0.102: [GC0.102: [ParNew: 20024K->497K(39296K), 0.0046067 secs] 20024K->9715K(126720K), 0.0046827 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
0.172: [GC0.172: [ParNew: 19990K->599K(39296K), 0.0009549 secs]

'初始标记：STW，单线程（可以从user和real几乎相等看出），只标记ROOT能直接可达的对象，一般应该很快'
'786428K表示年老代已占用空间；后面的786432K表示年老代总空间'
221810.417: [GC [1 CMS-initial-mark: 786428K(786432K)] 4527562K(5740992K), 3.1298768 secs] [Times: user=3.14 sys=0.00, real=3.16 secs] 
221813.547: [CMS-concurrent-mark-start]
'并发标记阶段，不会STW'
221814.218: [CMS-concurrent-mark: 0.670/0.671 secs] [Times: user=2.46 sys=0.00, real=0.64 secs] 
'预清理，不会STW。该阶段检查并发标记阶段时从新生代晋升的对象、新分配的对象、被应用程序线程更新过的对象，减少重新标记阶段的暂停时间'
221814.218: [CMS-concurrent-preclean-start]
221814.223: [CMS-concurrent-preclean: 0.005/0.005 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
'如果Eden占用量大于CMSScheduleRemarkEdenSizeThreshold（默认2M），会启动可中断预清理（不会STW）'
221814.223: [CMS-concurrent-abortable-preclean-start]
221814.223: [CMS-concurrent-abortable-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
'预清理阶段只是一个取样过程，它将新生代按一定间隔进行分块，标记起始位置，以便remark时可以并行的的对块进行Trace'
'预清理阶段最好发生一次YGC，-XX:CMSScavengeBeforeRemark可以强制重标记前发生YGC'
    221814.224: [GC[YG occupancy: 3774483 K (4954560 K)]
    221814.224: [Rescan (parallel) , 4.1513281 secs]
    221818.375: [weak refs processing, 0.0000280 secs]
    221818.375: [scrub string table, 0.0014394 secs] 
        '重新标记，STW，多线程，默认通过-XX:ParallelGCThreads计算得到线程数，此阶段通常是CMS中暂停时间最长的'
        [1 CMS-remark: 786428K(786432K)] 4560911K(5740992K), 4.1529812 secs] [Times: user=28.08 sys=0.00, real=4.17 secs] 

'并发清理，不会STW'
221818.377: [CMS-concurrent-sweep-start]
CMS: Large Block: 0x00000007f8000000; Proximity: 0x00000007f7851ea0 -> 0x00000007f7851ea0
CMS: Large block 0x0000000000000000
221818.736: [CMS-concurrent-sweep: 0.358/0.358 secs] [Times: user=0.87 sys=0.00, real=0.36 secs] 
'重置，CMS数据结构重新初始化，为下一次CMS做准备'
221818.736: [CMS-concurrent-reset-start]
221818.738: [CMS-concurrent-reset: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

'紧跟着一次并发模式失败的Full GC'
221890.743: [GC221890.743: [ParNew: 18434K->18434K(39296K), 0.0000233 secs]90.743: [CMS90.743: [CMS-concurrent-abortable-preclean: 0.000/0.028 secs] [Times: user=0.02 sys=0.00, real=0.03 secs] 
 (concurrent mode failure): 83535K->37453K(87424K), 0.0111540 secs] 101969K->37453K(126720K), [CMS Perm : 3284K->3284K(65536K)], 0.0112398 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
221890.754: [Full GC221890.754: [CMS: 37453K->37453K(87424K), 0.0051618 secs] 37453K->37453K(126720K), [CMS Perm : 3284K->3284K(65536K)], 0.0051982 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

开启：-XX:+PrintTenuringDistribution可以打印分布信息

'期望的Survivor区占用由-XX:TargetSurvivorRatio=50指定'
'threshold 即晋升的年龄限制，可由-XX:MaxTenuringThreshold指定'
Desired survivor size 2228224 bytes, new threshold 6 (max 6)
- age   1:        232 bytes,        232 total
- age   2:     478840 bytes,     479072 total '各年龄对象的字节数、数量'

开启-XX:+PrintGCApplicationConcurrentTime、-XX:+PrintGCApplicationStoppedTime可以打印并发时间、停顿时间

'应用和GC并发执行的时间'
Application time: 0.0362382 seconds
'应用被GC停止的时间'
Total time for which application threads were stopped: 0.0039536 seconds

开启 -XX:+PrintFlagsFinal可以打印所有GC标记

[Global flags]
    uintx AdaptivePermSizeWeight                    = 20              {product}           
    uintx AdaptiveSizeDecrementScaleFactor          = 4               {product}           
    uintx AdaptiveSizeMajorGCDecayTimeScale         = 10              {product}           
    ……

开启-XX:PrintFLSStatistics=1可以统计内存碎片

Before GC:
Statistics for BinaryTreeDictionary:
------------------------------------
Total Free Space: 11190272
Max   Chunk Size: 11190272
Number of Blocks: 1
Av.  Block  Size: 11190272
Tree      Height: 1

After GC:
Statistics for BinaryTreeDictionary:
------------------------------------
Total Free Space: 9993976
Max   Chunk Size: 9993976
Number of Blocks: 1
Av.  Block  Size: 9993976
Tree      Height: 1

The post JVM参数与性能调优 appeared first on 绿色记忆.

根据Java虚拟机规范，在运行时，JVM管理的内存分为以下区域：

其中：方法区和堆被所有线程共享，其它三个区域则是线程私有，这些区域的功能如下：

除了上述的运行时区域以外，还有一块内存区域叫直接内存（Direct Memory）。 NIO类库引入了一种基于通道（Channel) 与缓冲区（Buffer)的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作，避免在Java堆和Native堆中来回复制数据以提高性能。

除了程序计数器以外，其它区域均可能发生OOM异常。

考虑最简单的代码：Object obj = new Object();

1. Object obj 将映射到Java栈的本地变量表中，作为Reference类型出现
2. new Object()将反映到Java堆中，形成一块存储Object类型实例数据值（对象各字段数据）的结构化内存
3. 关于Object类的类型信息（Class、父类、接口、方法等）存放于方法区

引用类型的两种实现方式：

1. 使用句柄：堆中划分单独区域作为句柄池，Reference中存放的为对象句柄地址，而句柄中包含对象实例数据、类型数据各自的具体地址
2. 直接指针：Reference直接存放对象的地址，需要考虑类型数据的布局。Hostspot使用的是这种方式

OS对于单个进程的内存是有限制的，对于32位Windows，进程内存的上限为2GB。

JVM进程总内存 = Xmx + MaxPermSize+ 程序计数器 + JVM进程本身内存消耗 + JVM栈 + 本地栈

JVM能创建的线程数，一方面受到OS对进程最大线程数的限制，一方面受到内存的限制：总可用栈内存/每个栈的大小。

给对象中添加一个引用计数器，每 当有一个地方引用它时，计数器值就加1，当引用失效时，计数器值就减1；任何时刻 计数器都为0的对象就是不可能再被使用的。

缺点：很难解决对象之间的相互循环引用的问题。

Java语言中具体垃圾回收算法均是根搜索算法的变体。通过一系列的名为“GC Roots”的对象作为起始点，从这些点开始向下搜索，搜索所 走过的路径称为引用链（Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用 的。在Java语言里，GC Roots对象可以是：

1. 虚拟机栈（栈帧中的本地变量表）中的引用的对象
2. 方法区中的类静态属性引用的对象
3. 方法区中的常量引用的对象
4. 本地方法栈中的引用的对象

1. Minor GC：只针对年轻代的GC，也称为Young GC
2. Full GC：针对年老代的GC，偶尔会伴随年轻代、永久代的GC，也称为Major GC

Jdk 6u22以后，可用的垃圾收集器有（年轻代年老代之间的连线表示可以组合使用）：

1. 对象优先在Eden分配，如果Eden空间不足，发生Minor GC
2. 大对象直接进入年老代：所谓大对象就是指，需要大量连续内存空间的Java对象（长字符串、数组）
3. 长期存活对象进入年老代：所谓长期，是指经历多次Minor GC仍然存活
4. 空间分配担保

1. 强引用：普通方式new的对象，均为强引用，这类对象不会被回收
2. 软引用：系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中并进行第二 次回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常
3. 弱引用：一旦垃圾回收器运作，即被回收，最多活到下一次垃圾回收之前
4. 幻引用：一个对象是否 有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是希望能在这个对象被收 集器回收时收到一个系统通知。

Class文件是一组以字节为基础单位的、格式紧凑的二进制流，如果某数据项需要超过8位，则按高位在前方式分割为若干字节存储。 

1. 无符号数：ul、u2、u4、u8分别代表1个字节、2个字节、 4个字节和8个字节的无符号数，无符号数可以用来描述数字、索引引用、数量值、Unicode编码的字符
2. 表是以多个无符号数、其他表作为数据项构成的复合类型，一般以 _info结尾。整个Class文件就是一张表：
   

   类型	名称	说明
   u4	magic	1个。用于确认是否为合法Class文件，为0xCAFEBABE
   u2	minor_version	1个。次版本号
   u2	major_version	1个。主版本号
   u2	constant_pool_count	1个。记录常量池条目的数量
   cpinfo	constant_pool	constant_pool_count - 1个。此容器的计数从1开始。主要包括两类常量：字面量（Literal)和符号引用（Symbolic Reference），字面量包括字符串、声明为final的常量值。符号引用包括： 类和接口的全限定名（Fully Qualified Name) 字段的名称和描述符（Descriptor) 方法的名称和描述符 Java与C不同，不存在"链接"的编译步骤，而是在JVM加载class文件时动态链接——class文件中不包含方法、字段 的内存布局信息——通过符号引用进行翻译，得到具体内存地址
   u2	access_flags	1个。识别一些类或接口层次的访问信息，包括：这个Class是类还是接口 、是否定义为 public类型、是否定义为abstract类型、如果是类的话，是否被声明为final，等等
   u2	this_class	1个。类索引（指向常量池）
   u2	superclass	1个。父类索引（指向常量池）
   u2	interfaces_count	1个。接口个数
   u2	interfaces	interfaccs_count个。接口索引集合（指向常量池）
   u2	fields_count	1个。字段个数
   field_info	fields	fields_count个。字段表包含字段的各种限定符、描述符、名字索引等信息。字段表集合中不会列出从超类或父接口中继承而来的字段。 结构： u2 access_flags 1，字段访问标记，参考下面的表格 u2 name_index 1，简单名称的索引 u2 descriptor_index，描述符的索引 u2 attributes_count，属性的个数 attribute_info attributes attributes_count 属性用于描述一些额外的信息
   u2	methods_count	1个。方法个数
   method_info	methods	methods_count个。方法表包含字段的各种限定符、描述符、名字索引等信息 结构： u2 access_flags 1，方法访问标记，参考下面的表格 u2 name_index 1，简单名称的索引 u2 descriptor_index，描述符的索引 u2 attributes_count，属性的个数 attribute_info attributes attributes_count 属性用于描述一些额外的信息，包括表示方法的代码的Code属性。
   u2	attributes_count	1个。
   attribute_info	attributes	attributes_count个。属性表 结构： u2 attribute_name_index 1 属性名称在常量池的索引 u2 attribute_length 1 属性长度 u1 info attribute_length 属性内容

常量池是Class文件结构中与其他项目关联最多的数据类型，也是占用Class文件空间最大的数据项目之一。

常量池中的每一项常量都是一个表，共有11种结构各不相同的表结构数据，这11 种表都有一个共同的特点，就是表开始的第一位是一个u1类型的标志位，代表当前这个常量属于哪种常量类型：

在常量池结束之后，紧接着的2个字节代表访问标志（access_flags)：

字段表的前两个字节：

方法表的前两个字节：

描述符标识符列表：

描述方法时，按如下规则：

1. 先参数列表，后返回值。例如：void ific()描述为()V
2. 参数按声明顺序放置于()内。例如：int compare(Object o1,Object o2)描述为(Ljava/lang/ObjectLjava/lang/Object)I

在Class文件、字段 表、方法表中都可以携带自己的属性表集合，以用于描述某些场景专有的信息。JVM规范中预定义了9项虚拟机实现应当能识別的属性：

1. 加载：JVM规范没有规定何时加载类，实行根据需要决定。加载阶段需要完成3件事：
   a) 通过一个类的全限定名来获取定义此类的二进制字节流
   b) 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
   c) 在Java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口
2. 验证：确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。包括文件格式验证、元数据验证、字节码验证、符号引用验证等步骤
3. 准备：为类变量分配内存并设置类变量初始值，这些内存都在方法区中分配。
4. 解析：是将常量池内的符号引用替换为直接引用的过程。包括接口和类解析、字段解析、类方法解析、接口方法解析
5. 初始化：是执行类构造方法()的过程（此方法收集静态变量赋值、static代码块自动生成），虚拟机保证多线程环境下()方法被正确的加锁与同步。以下情况，如果类尚未初始化，则需要触发初始化。遇到 new、getstatic、putstatic 或 invokestatic 这 4 条字节码指令时；当通过反射调用时；父类未初始化时，首先初始化父类；虚拟机启动时，初始化main函数所在类

比较两个类是否“相 等”，只有在这两个类是由同一个类加载器加载的前提之下才有意义。

从JVM的角度，类加载器只分为两类：一种是启动类加载器 (Bootstrap ClassLoader)，这个类加栽器使用C++语言实现，是虚拟机自身的一部分； 另外一种就是所有其他的类加载器，这些类加栽器都由Java语言实现且全都继承自抽象类java.lang.ClassLoader。

从开发人员角度，类加载器可以细分为：

所谓双亲委派模型，指出了启动类加载器外，所有ClassLoader都可通过getParent()得到父加载器。通常，如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加 载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当 父加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己加载。

线程上下文 类加载器（Thread Context ClassLoader)可以通过java.lang.Thread类的 setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承。

栈帧（Stack Frame)是用于支持JVM进行方法调用和方法执行的数据结构，是JVM运行时数据区中的虚拟机栈的栈元素。栈帧存储了方法的局部变量表、操作数栈、动态链接和方法返回地址等信息。方法从调用开始到执行完成的过程，就对应着一个栈帧在虚拟机栈里面从入栈到出栈的过程。对于执行引擎来讲，只有栈顶的栈帧是有效的，称为当前栈帧（Current Stack Frame)，这个栈帧所关联的方法称为当前方法（Current Method)。执行引擎所运行的所有字节码指令都只针对当前栈帧进行操作，栈帧结构示意图如下：

局部变量表的容量以变量槽（Variable Slot,下称Slot)为最小单位，每个Slot 都应该能存放一个 boolean、byte、char、short、int、float、reference 或 retumAddress 类型的数据（即一般的说Slot大小为32bits）

虚拟机通过索引定位的方式使用局部变量表，索引值的范围是从0开始到局部变量 表最大的Slot数量。对于Long、Double占用2个Slot，高位在前

对于块级作用域的变量，其Slot可以被重用

也称为操作栈，每个栈元素可以是任意Java类型，Long、Double占用两个栈容量。当方法开始执行时，操作数栈是空的，其后会有各种字节码指令向操作数栈中写入和提取内容，也就是入栈出栈操作。例如， 在做算术运算的时候是通过操作数栈来进行的，又或者在调用其他方法的时候是通过操作数栈来进行参数传递的。

每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用 是为了支持方法调用过程中的动态连接

方法退出有两种方式：

1. 执行引擎遇到方法返回的字节码指令，这时候可能会有返回值传递给上层的方法调用者，这种退出方法的方式称为正常完成出口
2. 方法执行过程中遇到了异常，并且这个异常没有在方法体内得到处理，无论是Java虚拟机内部产生的异常，还是代码中使用athrow字节码指令 产生的异常，只要在本方法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，这种退出方法的方式称为异常完成出口

方法退出后需要返回到方法被调用的位置，程序才能继续执行，方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层方法的执行状态。一般来说，方法正常退出时，调用者的PC计数器的值就可以作为返回地址，栈帧中很可能会保存这个计数器值。而方法异常退出时，返回地址是要通过异常处理器表来确定。方法退出时可能执行的操作有：

1. 恢复上层方法的局部变量表和操作数栈
2. 把返回值（如果有的话）压入调用者栈帧的操作数栈中
3. 调整PC计数器的值以指向方法调用指令后面的一条指令

为了获得较好的执行效能，JMM不限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器调整代码执行顺序。

JMM规定了所有的变量都存储在主内存（Main Memory，相当于物理内存)中。每条线程还有自己的工作内存（Working Memory，相当于处理器高速缓存、寄存器），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝， 线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。

JMM定义了8种原子性操作来确定工作内存与主内存如何交互：

1. lock (锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态
2. unlock (解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来， 释放后的变量才可以被其他线程锁定
3. read (读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的 工作内存中，以便随后的load动作使用
4. load (载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中
5. use (使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执 行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作
6. assign (赋值作用于工作内存的变量，它把一个从执行引擎接收到的值陚值 给工作内存的变量，每当虚拟机遇到一个给变量陚值的字节码指令时执行这个操作
7. store (存储）：作用于工作内存的变董，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用
8.  write (写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中

JMM还规定了在执行上述八种基本操作时必须满足如下规则：

1. 不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况出现
2. 不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存
3. 不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中
4. 一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign)的变量，换句话说就是对一个变量实施use和store操作之前，必须先执行过了 assign和load操作
5. 一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作， 变量才会被解锁
6. 如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值
7. 如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定住的变量
8. 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行sotre 和write操作）

关键字volatile可以说是Java虚拟机提供的最轻量级的同步机制。

当一个变量被定义成volatile之后，它将具备两种特性：

1. 第一是保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。而普通变量不能做到这一点，变量值在线程间传递均需要通过主内存来完成，如：线程A修改一个普通变量的值，然后向主内存进行回写，另外一条线程B在线程A回写完成了之后再从主内存进行读取操作，新变量的值才会对线程B可见。
2. 第二是禁止指令重排序优化，普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变 量赋值操作的顺序与程序代码中的执行顺序一致

但是volatile并不保证操作的原子性，在不符合以下两条规则的运算场景中，仍要通过加锁来保证原子性：

1. 运算结果并不依赖变量的当前值（例如简单setter），或者能够确保只有单一的线程修改变量的值
2. 变量不需要与其他的状态变量共同参与不变约束

对于64位的数据类型（long和double)，JMM允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次进行。但是实际上，商业JVM基本上都把64位数据的读写操作作为原子操作实现。

1. 原子性（Atomicity）：由Java内存模型来直接保证的原子性变量操作包括read、 load、assign、use、store和write这六个，我们大致可以认为基本数据类型的访问读写是具备原子性的。如果需要在大范围实现原子性，lock、unlock操作可以完成（对应JVM指令monitorenter 、monitorexit，在代码上反映为Synchronized代码块）
2. 可见性（Visibility）：当一个线程修改了共享变量的值，其他线程能够 立即得知这个修改。volatile保证了多线程 操作时变置的可见性，而普通变量则不能保证这一点。synchronized、final也可以实现可见性
3. 有序性（Ordering)：天然的有序性：如果在本线程内观察，所有的操作都是有序的。在另一个线程观察，所有的操作都是无序的——指令重排、工作内存和主内存同步延迟的影响导致无序。volatile、synchronized提供有序性保证

“先行发生”（happens-before)的原则非常重 要，它是判断数据是否存在竞争，线程是否安全的主要依据。下面是Java内存模型下一些“天然的”先行发生关系（无需任何同步保证手段）：

1. 程序次序规则（Program Order Rule)：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作
2. 监视器锁定规则（Monitor Lock Rule)：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁，而“后面”是指时间上的先后顺序
3. volatile变量规则 (Volatile Variable Rule)：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后顺序
4. 线程启动规则（Thread Start Rule) ：Thread对象的start()方法先行发生于此线程的每一个动作
5. 线程终止规则（Thread Termination Rule)：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行
6. 线程中断规则（Thread Interruption Rule)：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测到是否有中断发生
7. 对象终结规则（Hnalizer Rule)：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始
8. 传递性（Transitivity)：如果操作A先行发生于操作B，操作B先行发生于操作 C，那么操作A先行发生于操作C

Java中线程的实现具有以下几种方式：

1. 使用内核线程实现。内核线程（Kernel Thread, KLT）就是直接由操作系统内核支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器（Scheduler)对线程进行调度，并负责将线程的任务映射到各个处理器上。
   程序一般不会直接去使用内核线程，而是去使用内核线程的一种髙级接口——轻量级进程（Light Weight Process, LWP)。轻量级进程就是我们通常意义上所讲的线程，由于每个轻量级进程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程之间1:1的关系称为一对一的线程模型
2. 使用用户线程实现。狭义上的用户线程指的是完全建立在用户空间的线程库上，系统内核不能感知到线程存在的实现。用户线程的建立、同步、销毁和调度完全在用户态中完成，不需要内核的帮助。如果程序实现得当，这种线程不需要切换到内核态，因此操作可以是非常快速且低消耗的，也可以支持规模更大的线程数量
3. 混合实现：既存在用户线程，也存在轻量级进程。用户线程还是完全建立在用户空间中，因此用户线程的创建、切换、析构等操作依然廉价，并且可以支持大规模的用户线程并发。而操作系统提供支持的轻量级进程则作为用户线程和内核线程之间的桥梁，这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级线程来完成，大大降低了进程被阻塞的风 险。在这种混合模式中，用户线程与轻量级进程的数量比是不定的，是M:N的关系

Java语言定义了 5种进程状态：

1. 新建（New）：创建后尚未启动的线程处于这种状态
2. 运行（Runable）：Runable包括了操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能正在等待着CPU为它分配执行时间
3. 无限期等待（Waiting）：处于这种状态的进程不会被分配CPU执行时间，它们要等待被其他线程显式地唤醒。以下方法会让线程陷入无限期的等待状态：
   a) 没有设置Timeout参数的Object.wait()方法
   b) 没有设置Timeout参数的Thread.join()方法
   c) LockSupport.park()方法
4. 限期等待（Timed Waitting）：处于这种状态的进程也不会被分配CPU执行时间， 不过无须等待被其他线程显式地唤醒，在一定时间之后它们会由系统自动唤醒。 以下方法会让线程进入限期等待状态：
   a) Thread. sleep()方法
   b) 设置了 Timeout 参数的 Object.wait()方法
   c) 设置了 Timeout 参数的 Thread.join()方法
   d) LockSupport.parkNanos() 方法
   e) LockSupport.parkUntil()方法
5. 阻塞（Blocked）：进程被阻塞了，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等待着获取到一个排它锁，这个事件将在另外一个线程放弃这个锁的时候发生；而“等待状态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态。
6. 结束（Terminated）：已终止线程的线程状态，线程已经结束执行

当多个线程访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那这个对象就是线程安全的。

按照线程安全的级别，可以按线程安全强度把共享数据分为5类：

1. 不可变对象：例如字符串、数字的部分子类、枚举
2. 绝对线程安全：完全满足上述关于线程安全的定义。即使多个线程同时对这个对象进行一系列顺序的操作，也不会出现意外的结果
3. 相对线程安全：通常意义上所讲的线程安全，它需要保证对这个对象单独的操作是线程安全的，我们在调用的时候不需要做额外的保障措施。在Java语言中，大部分的线程安全类都属于这种类型，例如Vector、HashTable、 Collections.synchronizedCollection()方法包装的集合等
4. 线程兼容：是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中安全地使用，我们平常说一个类不是线程安全的，绝大多数指的都是这种情况。Java API中大部分的类都是线程兼容
5. 线程对立：是指不管调用端是否采取了同步措施，都无法在多线程环境中并发使用的代码。由于Java语言天生就具备多线程特性，线程对立这种排斥多线程的代码是很少出现。一个线程对立的例子是Thread类的suspend()和resume()方法

1. 互斥同步（Mutual Exclusion & Synchronization)：是最常见的一种并发正确性保障手段，同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条 (或者是一些，使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区 (Critical Section)、互斥量（Mutex)和信号量（Semaphore)都是主要的互斥实现方式。在Java里面，最基本的互斥同步手段就是synchronized关键字。synchronized是Java语言中一个重量级的操作，虚拟机会进行一些优化，譬如在通知操作系统阻塞线程之前加入一段自旋等待过程，避免频繁地切入到内核态中。除了 synchronized之外，还可以使用java.util.concurrent的重入锁（ReentrantLock)来实现同步，在基本用法上，ReentrantLock与synchronized 很相似，他们都具备一样的线程重入特性，只是代码写法上有点区别，一个表现为API 层面的互斥锁（lock和unloek方法配合try/fmally语句块来完成），一个表现为原生语法层面的互斥锁。不过ReentrantLock比synchronized增加了一些髙级功能，主要有以下三项：
   a) 等待可中断：当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择 放弃等待，改为处理其他事情，可中断特性对处理执行时间非常长的同步块很有帮助
   b) 公平锁：多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非公平的，ReentrantLock默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁
   c) 锁绑定多个条件：一个ReentrantLock对象可以同时绑定多个Condition对象， 而在synchronized中，锁对象的wait()和notify()或notifyAll()方法可以实现一个隐含的条件，如果要和多于一个的条件关联的时候，就不得不额外地添加一个 锁，而ReentrantLock则无须这样做，只需要多次调用newCondition()方法即可
2. 非阻塞同步：随着硬件指令集的发展，可以使用基于冲突检测的乐观并发策略。Atomiclnteger就是这样的例子
3. 无同步方案：
   a) 可重入代码：也叫纯代码（Pure Code），可以在代码执行的任何时刻中断它，转而去执行另外一段代码（包括递归调用它本身），而在控制权返回后，原来的程序不会出现任何错误。可重入代码有一些共同的特征：例如不依赖存储在堆上的数据和公用的系统资源、 用到的状态量都由参数中传入、不调用非可重入的方法等。
   b) 线程本地存储（Thread Local Storage）

互斥同步对性能最大的影响是阻塞的实现， 挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性能带来 了很大的压力。在许多应用上，共享数据的锁定状态 只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。如果物理机器有 一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一会儿”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只须让线程执行一个忙循环（自旋），这项技术就是 所谓的自旋锁。

自旋锁在JDK1.6以后默认开启。使用-XX:+UseSpinning可以强制开启。自旋默认值是10次，可以使用参数-XX:PreBlockSpin来更改。

在JDK 1.6中引入了自适应的自旋锁。自旋的时间由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象 上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。

对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持。

大部分情况下，倾向于将同步块的作用范围限制得尽量小，但是如果一系列的连续操作都对同一个对反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地 进行互斥同步操作也会导致不必要的性能损耗。

轻量级锁是JDK 1.6中加入的新型锁机制，它名字中的“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的。首先 需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了 使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了 CAS操 作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。

偏向锁也是JDK 1.6中引入的一项锁优化，它的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS 操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉， 连CAS操作都不做了。偏向锁可以提高带有同步但无竞争的程序性能。如果程序中大多数的锁都总是被多个不同的线程访问，那偏向模式就是多余的。有时候使用参数-XX:-UseBiasedLocking来禁止偏向锁优化反而可以提升性能。

逃逸分析是一种可以有效减少Java 程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。

在计算机语言编译器优化原理中，逃逸分析是指分析指针动态范围的方法，它同编译器优化原理的指针分析和外形分析相关联。当变量（或者对象）在方法中分配后，其指针有可能被返回或者被全局引用，这样就会被其他过程或者线程所引用，这种现象称作指针（或者引用）的逃逸（Escape）。

Java在Java SE 6u23以及以后的版本中支持并默认开启了逃逸分析的选项。Java的 HotSpot JIT编译器，能够在方法重载或者动态加载代码的时候对代码进行逃逸分析，同时Java对象在堆上分配和内置线程的特点使得逃逸分析成Java的重要功能。

经过逃逸分析之后，可以得到三种对象的逃逸状态：

1. GlobalEscape（全局逃逸）， 即一个对象的引用逃出了方法或者线程
2. ArgEscape（参数级逃逸），即在方法调用过程当中传递对象的引用给一个方法
3. NoEscape（没有逃逸），一个可以进行标量替换的对象。可以不将这种对象分配在传统的堆上

编译器可以使用逃逸分析的结果，对程序进行以下优化：

1. 堆分配对象变成栈分配对象。一个方法当中的对象，对象的引用没有发生逃逸，那么这个方法可能会被分配在栈内存上而非常见的堆内存上
2. 消除同步。线程同步的代价是相当高的，同步的后果是降低并发性和性能。逃逸分析可以判断出某个对象是否始终只被一个线程访问，如果只被一个线程访问，那么对该对象的同步操作就可以转化成没有同步保护的操作，这样就能大大提高并发程度和性能
3. 矢量替代。逃逸分析方法如果发现对象的内存存储结构不需要连续进行的话，就可以将对象的部分甚至全部都保存在CPU寄存器内，这样能大大提高访问速度

逃逸分析对应的JVM参数是 -XX:+DoEscapeAnalysis

The post JVM学习笔记 appeared first on 绿色记忆.

该视图专注于对象的内存分配情况，包含以下选项卡：

All Objects	显示堆中实时的对象情况：显示某种类型（聚合级别可以是类、包等）对象的数量（Instance Count）、浅尺寸（Shallow size）关于浅尺寸的计算： 普通对象大小的计算不包括引用、类变量，由变量本身地址、基本类型的变量占用的内存等组成 数组整体计算，不分为单个元素计算大小/数量 注意，有些对象虽然没有引用，但是可能没被GC回收，可以手工Run GC 右击某一类型，可以转到Class Tracker或者Heaper Walker视图
Recorded Objects	显示已经进行记录的对象。与All Objects相比，可以查看对象分配调用树（Allocation Call Tree）、分配热点（Allocation Hot Sports）点击工具栏：Start Memory，可以录制对象分配
Allocation Call Tree	显示选中的、已录制对象类型的分配调用数，分析调用栈的哪些栈帧比较消耗资源。从线程执行开始处，一直追溯到对象被创建的地方，对象占用内存的大小被显示，效果如下图：
Allocation Hot Sports	显示选中的、已录制对象类型的分配热点：以创建对象的方法为根显示调用树，效果如下图：
Class Tracker	显示选中类型对象的实例个数的曲线图（按时间）

该视图用于静态分析堆快照，在生成快照之前，会进行一次Full GC。包含以下选项卡：

该视图用于分析方法的CPU占用时间，包括以下选项卡：

该视图用于分析线程的状态和历史分析、检测死锁，并可以获取线程快照，包含以下选项卡：

Thread History	线程状态时间线，可以选择显示活着的或者死去的线程 绿色：Runnable：表示线程可以接受CPU调度，但不一定正在占用CPU，和线程优先级、调度算法、系统负载有关 黄色：Waiting：表示线程正在睡眠（java.lang.Thread.Sleep），或者在监视器上等待（java.lang.Object.wait），前者不会放弃占有的监视器 红色：Blocked：表示线程被阻塞，正在积极尝试进入同步区 浅蓝色：Net I/O：线程正在等待网络操作的完成，监听Socket或者读写Socket时产生此状态 效果图如下：
Thread Monitor	显示线程的开始结束时间、父线程、状态等信息
Thread Dumps	获取线程快照，可以分析瞬时系统各线程的调用栈

该视图用于锁状态检测，包含以下选项卡：

该视图可以显示时间线上的系统宏观信息，包括以下选项卡：

可以使用多种探针来检测不同的应用领域，包括：JDBC、JPA/Hibernate、JNDI、JMS、Servlet、RMI、Socket、WebServices、Files等。

用于在特定条件下触发剖析动作
触发条件：方法被调用、堆使用阈值、CPU使用率阈值、内存溢出异常、定时器、虚拟机启动、虚拟机关闭等
剖析动作：启/停录制、调用跟踪、监视器跟踪，触发堆dump、线程dump，启/停探针录制，保存快照，保存HPROF快照，运行脚本等

使用场景：脚本启动剖析、定期快照保存、剖析远程服务器

java 
"-agentpath:D:\JavaEE\jprofiler\7.2.2\bin\windows-x64\jprofilerti.dll=offline,id=109,config=D:\JavaEE\Config\jprofiler-offline.xml"
"-Xbootclasspath/a:D:\JavaEE\jprofiler\7.2.2\\bin\agent.jar"
-classpath myapp.jar cc.gmem.demo.MyApp

The post JProfiler学习笔记 appeared first on 绿色记忆.