重装WIN10系统后标准NVM Express控制器出现叹号

##4.1 JDK的命令行工具## JDK的命令行工具大多数是jdk/lib/tools.jar类库的一层薄包装而已，它们主要的功能代码是在tools类库中实现的。假如读者使用的是Linux版本的JDK，还会发现这些工具中很多甚至就是由Shell脚本直接写成的，可以用vim直接打开它们。

JDK开发团队选择采用Java代码来实现这些监控工具是有特别用意的：当应用程序部署到生产环境后，无论是直接接触物理服务器还是远程Telnet到服务器上都可能会受到限制，借助tools.jar类库里面的工具，我们可以直接在应用程序中实现功能强大的监控分析功能。

注意：如果在工作中需要监控运行于JDK 1.5的虚拟机之上的程序，在程序启动时请添加参数“-Dcom.sun.management.jmxremote”开启JMX管理功能，否则由于部分工具都是基于JMX，它们都将无法使用；如果被监控程序运行于JDK 1.6的虚拟机之上，那JMX管理默认是开启的，虚拟机启动时无须再添加任何参数。 ###4.1.1 jps：虚拟机进程状况工具### jps功能也和ps命令类似：可以列出正在运行的虚拟机进程，并显示虚拟机执行主类（Main Class，main()函数所在的类）名称以及这些进程的本地虚拟机唯一ID（Local Virtual Machine Identifier，LVMID）。对于本地虚拟机进程来说，LVMID与操作系统的进程ID（Process Identifier，PID）是一致的

命令1：jps -l：输出主类的全名，如果进程执行的是Jar包，输出Jar路径；

命令2：jps -v：输出虚拟机进程启动时JVM参数；

命令3：jps -m：输出虚拟机进程启动时传递给主类main()函数的参数；

命令4：jps -q：只输出LVMID，省略主类的名称；

###4.1.2 jstat：虚拟机统计信息监视工具### jstat（JVM Statistics Monitoring Tool）是用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程虚拟机进程中的类装载，内存，垃圾收集，JIT编译等运行数据。在没有GUI图形界面，只提供了纯文本控制台环境的服务器上，它将是运行期定位虚拟机性能问题的首选。

jstat命令格式为：jstat [option vmid [interval [s | ms] [count]]]

对于命令格式中的VMID与LVMID需要特别说明一下：如果是本地虚拟机进程，VMID与LVMID是一致的，如果是远程虚拟机进程，那VMID的格式应当是：

[protocol:][//]lvmid[@hostname[:port]/servername] 注：需要远程主机RMI支持，Sun提供的jstatd工具可以很方便的建立远程RMI服务器。

命令1：jstat -gc 13991 200 5：每200毫秒查询一次进程2764垃圾收集状况，一共查询5次；

命令2：jstat -gcutil 13991 200 5：监视内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比；

上图中“E”表示Eden区使用空间百分比；“S0”“S1”表示两个Survivor区使用空间百分比；“O”表示老年代使用空间百分比；“P”表示永久代使用空间百分比；“YGC”表示新生代GC次数；“YGCT”表示新生代GC总耗时毫秒；“FGC”表示老年代GC次数；“FGCT”表示老年代GC总耗时毫秒；“GCT”表示GC总耗时毫秒；

###4.1.3 jinfo：Java配置信息工具### jinfo的作用是实时地查看和调整虚拟机各项参数。使用jps命令的-v参数可以查看虚拟机启动时显示指定的参数列表，但如果想知道未被显示指定的参数系统默认值，除了去找资料外，就只能使用jinfo的-flag选项进行查询了（如果只限于JDK 1.6或以上版本的话，使用java -XX:+PrintFlagsFinal查看参数默认值也是一个很好的选择），jinfo还可以使用-sysprops选项把虚拟机进程的System.getProperties()的内容打印出来。可以使用-flag [+|-] name或者 -flag name=value修改一部分运行期可写的虚拟机参数值。命令1：jinfo -flag CMSInitiatingOccupancyFraction 13991：查询CMSInitiatingOccupancyFraction参数值。

###4.1.4 jmap：Java内存映射工具### jmap命令用于生成堆转储快照（一般称为heapdump或dump文件）。如果不使用jmap命令，要想获取Java堆转储快照，还有一些比较“暴力”的手段：譬如通过-XX:+HeapDumpOnOutOfMemoryError参数，可以让虚拟机在OOM异常出现之后自动生成dump文件；通过-XX:+HeapDumpOnCtrlBreak参数则可以使用[Ctrl] + [Break]键让虚拟机生成dump文件；或者在Linux系统下通过kill -3命令发送进程退出信号“吓唬”一下虚拟机，也能拿到dump文件。

jmap的作用并不仅仅是为了获取dump文件，它还可以查询finalize执行队列，Java堆和永久代的详细信息，如：空间使用率，当前使用的是哪种收集器等。

命令1：jmap -dump:format=b,file=idea.bin 13991

###4.1.5 jhat：虚拟机堆转储快照分析工具### Sun JDK提供jhat命令与jmap搭配使用，来分析jmap生成的堆转储快照。jhat内置了一个微型的HTTP/HTML服务器，生成dump文件的分析结果后，可以在浏览器中查看。不过实事求是地说，在实际工作中，很少使用jhat命令来分析dump文件，主要原因有二：（1）一般不会在部署应用程序的服务器上直接分析dump文件，即时可以这样做，也会尽量将dump文件复制到其他机器上进行分析，因为分析工作是一个耗时而且消耗硬件资源的过程；（2）jhat命令分析功能相对来说比较简陋。

命令1：jhat idea.bin ###4.1.6 jstack：Java堆栈跟踪工具### jstack命令用于生成虚拟机当前时刻的线程快照。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如：线程死锁，死循环，请求外部资源导致的长时间等待都是导致线程长时间停顿的常见原因。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以直到没有响应的线程到底在后台做写什么事情，或者等待着什么资源。

命令1：jstack -l 31069：除堆栈外，显示关于锁的附加信息； 命令1：jstack -F 31069：当正常输出的请求不被响应时，强制输出线程堆栈； 命令1：jstack -m 31069：如果调用到本地方法的话，可以显示C/C++的堆栈；

在JDK 1.5中，java.lang.Thread类新增了一个getAllStackTraces()方法用于获取虚拟机中所有线程的StackTraceElement对象。代码如下：

public class StackTraceTest {

	public static void main(String [] args) {
		for (Map.Entry<Thread, StackTraceElement[]> stackTrace : Thread.getAllStackTraces().entrySet()) {
			Thread thread = stackTrace.getKey();
			StackTraceElement [] stackTraceElements = stackTrace.getValue();

			if (thread.equals(Thread.currentThread())) {
				continue;
			}

			System.out.println("线程：" + thread.getName());
			for(StackTraceElement element : stackTraceElements) {
				System.out.println("\t" + element);
			}
		}
	}
}

###4.1.7 HSDIS：JIT生成代码反汇编### 随着技术的发展，高性能虚拟机真正的细节实现方式已经渐渐与虚拟机规范所描述的内容产生了越来越大的差距，虚拟机规范中的描述逐渐成了虚拟机实现的“概念模型”—即实现只能保证规范描述等效。基于这个原因，我们分析程序的执行语义问题（虚拟机做了什么）时，在字节码层面上分析完全可行，但分析程序的执行行为问题（虚拟机是怎样做的，性能如何）时，在字节码层面上分析就没有什么意义了，需要通过其他方式解决。

分析程序如何执行，通过软件调试工具来断点调试是最常见的手段，但是这样的调试方式在Java虚拟机中会遇到很大困难，因为大量执行代码是通过JIT编译器动态生成到CodeBuffer中的，没有很简单的手段来处理这种混合模式的调试。因此，不得不通过一些特别的手段来解决问题，基于这种场景，HSDIS插件终于登场了。

HSDIS是一个Sun官方推荐的HotSpot虚拟机JIT编译代码的反汇编插件，它包含在HotSpot虚拟机的源码之中，但没有提供编译后的程序。它的作用是让HotSpot的-XX:+PrintAssembly指令调用它来把动态生成的本地代码还原为汇编代码输出，同时还生成了大量非常有价值的注释，这样我们就可以通过输出的代码来分析问题。可以根据自己的操作系统和CPU类型从Project Kenai网站上下载编译好的插件，直接放到JDK_HOME/jre/bin/client和JDK_HOME/jre/bin/server目录中即可。如果没有找到所需操作系统的成品，那就得自己使用源码编译一下。（HLLVM圈子中有已编译好的）

还需要注意的是，如果使用的是Debug或者FastDebug版的HotSpot，那可以直接通过-XX:+PrintAssembly指令使用插件；如果使用的是Product版的HotSpot，那还需要额外加入一个-XX:+UnlockDiagnosticVMOptions参数。

package com.king.hsdis;

/**
 * @author taomk
 * @version 1.0
 * @since 15-4-20 下午9:27
 *
 * 虚拟机参数：
 * -XX:+PrintAssembly：输出反汇编内容；
 * -Xcomp：是让虚拟机以编译模式执行代码；
 * -XX:CompileCommand=dontinline,*Bar.sum：让编译器不要内联sum()；
 * -XX:CompileCommand=compileonly,*Bar.sum：只编译sum()；
 */
public class Bar {
	int a = 1;
	static int b = 2;

	public int sum(int c) {
		return a + b + c;
	}

	public static void main(String [] args) {
		new Bar().sum(3);
	}
}

注意：-Xcomp在较新的HotSpot中被移除了，如果虚拟机无法使用这个参数，请加个循环预热代码，触发JIT编译。 ##4.3 JDK的可视化工具## ###4.3.1 JConsole：Java监视与管理控制台### JConsole是一种基于JMX的可视化监视，管理工具，它管理部分的功能是针对JMX MBean进行管理，由于MBean可以使用代码，中间件服务器的管理控制台或者所有符合JMX规范的软件进行访问。 **1. 启动JConsole：**将自动搜索出本机运行的所有虚拟机进程，也还可以对远程进程监控（相当于jps）；

**2. 内存监控：**用于监视收集器管理的虚拟机内存（Java堆和永久代）的变化趋势（相当于jstat）。JConsole监视的代码，如下：

package com.king.jconsole;

import java.util.ArrayList;
import java.util.List;

/**
 * @author taomk
 * @version 1.0
 * @since 15-4-20 下午11:03
 *
 * 虚拟机参数：
 * -Xms100m
 * -Xmx100m
 * -XX:+UseSerialGC
 */
public class OOMForJConsole {
	static class OOMObject {
		public byte [] placeholder = new byte [64 * 1024];
	}

	public static void fillHeap(int num) throws InterruptedException {
		List<OOMObject> list = new ArrayList<>();
		for (int i = 0; i < num; i++) {
			Thread.sleep(50);
			list.add(new OOMObject());
		}
		System.gc();
	}

	public static void main(String [] args) throws InterruptedException {
		fillHeap(1000);
	}
}

通过JConsole监视，在“内存”页签中可以看到内存池Eden区的运行趋势呈现折线状。而监视范围扩大至整个堆后，会发现曲线是一条向上增长的平滑曲线。并且从柱状图可以看出，在1000次循环执行结束，运行了System.gc()后，虽然整个新生代Eden和Survivor区都基本清空了，但是代表老年代的柱状图仍然保持峰值状态，说明被填充进堆中的数据在System.gc()方法执行之后仍然存活。

问题：为何执行了System.gc()之后，老年代的柱状图仍然显示峰值状态，代码需要如何调整才能让System.gc()回收掉填充到堆中的对象？ 答案：执行System.gc()时，空间未能回收是因为List<OOMObject> list对象仍然存活，fillHeap()方法仍然没有退出，因此list对象在System.gc()执行时仍然处于作用域中。如果把System.gc()移动到fillHeap()方法外调用就可以回收掉全部内存。

注意：准确的说，只有在虚拟机使用解释器执行的时候，“在作用域之内”才能保证它不会被回收，因为这里的回收还涉及局部变量表Slot复用，即时编译介入时机等问题。

**3. 线程监控：**用于线程停顿时可以使用此进行监控（相当于jstack）；

package com.king.jconsole;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

/**
 * @author taomk
 * @version 1.0
 * @since 15-4-21 下午10:05
 */
public class ThreadForJConsole {

	/**
	 * 线程死循环
	 */
	public static void createBusyThread() {
		new Thread(new Runnable() {
			@Override
			public void run() {
				// Runnable状态的线程会被分配运行时间，而且没有归还线程执行令牌的动作，
				// 会在空循环上用尽全部执行时间直到线程切换，这种等待会消耗很多的CPU资源。
				while (true);
			}
		}, "testBusyThread").start();
	}

	public static void createLockThread(final Object lock) {
		new Thread(new Runnable() {
			@Override
			public void run() {
				try {
					// Runnable状态的线程在等待着lock对象的notify或notifyAll方法的出现，
					// 线程这时候处于WAITING状态，在被唤醒前不会被分配执行时间。
					lock.wait();
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
		}, "testLockThread").start();
	}

	public static void main(String [] args) throws IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

		// Runnable状态的线程会被分配运行时间，但readBytes方法检查到流没有更新时会立刻归还执行令牌，
		// 这种等待只消耗很小的CPU资源。
		br.readLine();
		createBusyThread();

		br.readLine();
		createLockThread(new Object());
	}
}

线程死锁代码：

package com.king.lock;

/**
 * @author taomk
 * @version 1.0
 * @since 15-4-21 下午10:28
 */
public class DeadLock {
	static class SynAddRunnable implements Runnable {
		int a, b;
		public SynAddRunnable(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) {
		for (int i = 0; i < 100; i++) {
			new Thread(new SynAddRunnable(1, 2)).start();
			new Thread(new SynAddRunnable(2, 1)).start();
		}
	}
}

造成死锁的原因是Integer.valueOf()方法基于减少对象创建次数和节省内存的考虑，[-128, 127]之间的数字会被缓存（默认值，实际值取决于java.lang.IntegerCache.high参数的设置），当valueOf()方法传入参数在这个范围之内，将直接返回缓存中的对象。假如在某个线程的两个synchronized块之间发生了一次线程切换，那就会出现线程A等着线程B持有的Integer.valueOf(1)，线程B又等着被线程A持有的Integer.valueOf(2)，结果出现大家都跑不下去的情景。

###4.3.2 Visual VM：多合一故障处理工具### Visual VM是到目前为止随JDK发布的功能最强大的运行监视和故障处理程序，并且可以预见在未来一段时间内都是官方主力发展的虚拟机故障处理工具。包括：运行监视，故障处理，性能分析等。而且Visual VM的还有一个很大的优点：不需要被监视的程序基于特殊Agent运行，因此它对应用程序的实际性能的影响很小，使得它可以直接应用在生产环境中。

注意：Visual VM是在JDK 1.6 update 7中才首次出现，但并不意味着它只能监控运行于JDK1.6上的程序，它具备很强的向下兼容能力。早于JDK 1.6的平台，需要打开-Dcom.sun.management.jmxremote参数才能被Visual VM管理。

1. Visual VM兼容范围与插件安装 （1）显示虚拟机进程以及进程的配置，环境信息（jps，jinfo）。 （2）监视应用程序的CPU，GC，堆，方法区以及线程的信息（jstat，jstack）。 （3）dump以及分析堆转储快照（jmap，jhat）。 （4）方法级的程序运行性能分析，找出被调用最多，运行时间最长的方法。 （5）离线程序快照：收集程序的运行时配置，线程dump，内存dump等信息建立一个快照，可以将快照发送开发者进行Bug反馈。 （6）其他plugins的无限的可能性。 2. 生成，浏览堆转储快照 3. 分析程序性能 在Profiler页签中，Visual VM提供了程序运行期间方法级的CPU执行时间分析以及内存分析，做Profiling分析肯定会对程序运行性能有比较大的影响，所以一般不在生产环境中使用这项功能。

如果是CPU分析，将会统计每个方法的执行次数，执行耗时；如果是内存分析，则会统计每个方法关联的对象数以及这些对象所占的空间。

注意：在JDK 1.5之后，在Client模式下的虚拟机加入并且自动开启了类共享——这是一个在多虚拟机进程中共享rt.jar中类数据以提高加载速度和节省内存的优化，而根据相关Bug报告的反映，Visual VM的Profiler功能可能会因为类共享而导致被监视的应用程序崩溃，所以进行Profiling前，最好在被监视程序中使用-Xshare:off参数来关闭类共享优化。 4. BTrace动态日志跟踪 BTrace的作用是在不停止目标程序运行的前提下，通过HotSpot虚拟机的HotSwap技术动态加入原本并不存在的调试代码。HotSwap技术：代码热替换技术，HotSpot虚拟机允许在不停止运行的情况下，更新已经加载的类的代码。