经过前几篇博文对堆内存以及垃圾收集机制的学习，相信小伙伴们已经建立了一套比较完整的理论体系！本篇博客就根据已有的理论知识，通过可视化工具来实践一番。
我们今天要讲解的工具位于JDK目录的bin目录下，大家可以发现该目录下有很多可执行文件，这里都是JDK为我们提供用于分析内存的一些工具。我们重点看看jconsole.exe，JAVA监视与管理控制台。
先运行以下程序： 
再双击运行可视化工具，这里会让你选择要监控的程序，我们选择刚刚运行的程序。结果如图： 
该页面只是一个概览页面，我们可以点进去上方导航栏的内存页，进去后我们可查看内存中各部分的使用情况图表，这里我们选择Eden区的查看。 
可看到内存使用呈锯齿波状态，因为我们在循环中不断的产生新对象，而新对象又在Eden区中创建，所以内存使用会不断增加，当达到所设定的最大值后就会进行内存的回收，由于每个新生的对象都被存入到了List中，因此都不属于垃圾对象（因为处于关系网中），所以就要复制到另一个Survivor中，如果另一个Survivor区也满了，就会复制到年老区了。可查看上图右下角绿色图，在运行中会动态更新的，变化情况和我刚刚说的是一样的。
当我们使用多线程的时候，会经常出现程序一直运行不会停止的情况，有可能出现死锁，有可能出现了死循环，可以通过该工具检测出来，先运行以下程序： 
再点击导航栏上的线程进入线程查看页： 
进入后页面长这个样子，看下方红色标记部分，根据我们刚刚执行的代码来看，代码开启了一个线程，作用就是执行死循环，线程的名字为默认的“Thread-0”。因为有了死循环，所以程序无法正常退出，查看堆栈跟踪，发现程序停在Test类的第14行，查看代码可发现那里是个死循环。注意：这里只是个测试例子，因此线程的名字用的是默认的，在实际环境中应为每个线程命名，在跟踪调试的过程中会大大减少工作量。
接下来我们来测试死锁的情况，运行以下代码： 
代码中线程1先申请obj1，再申请obj2；线程2先申请obj2，再申请obj1。如果执行次数多了就会出现死锁，我们依然来看线程的监控台： 
可以看出来，这么多的线程都处于等待中，不能正常退出，我们随机点一个查看，可以看到他的状态是BLOCKED。他需要的锁被线程31所持有。我们再看看31的线程（就不发图了），可以看到他需要的锁被线程30所持有。那么我们再看看30的线程，可以发现，30线程所需要的锁被31号线程所持有。他们互相等待，互相不释放，最终导致死锁，也导致后面那么多的线程处于BLOCKED状态。
这个可视化的工具我们就先讲这么多吧。从内存到线程，是我们在实际环境中不管是优化还是编码都会经常遇到的问题。