好吧，停止广告，daocloud再好，也不给我发钱，真是的。

这里就介绍一下我最简单的一个docker-tomcat容器。

首先在我的linux机器上安装docker：

安装教程特别多，随便可以找到，我的本地环境是64位的centos7.0，所以安装就被简化为：

Sudo yum install docker

这么一句话了。

docker的核心思想是everything is container，docker运行的就是一个个的容器，而容器是用户完全自定义的镜像，我个人认为最灵活的就是写一个dockerfile（我理解就算一个镜像了），然后把它build为镜像并run，一个可用的容器环境就完全起来了。

步骤：

1，创建一个项目，最好在git上

2，写Dockerfile文件，描述你的镜像

3，docker build

4，docker run

这样就好了。

于是，以我个人的项目为例：

1，创建项目：https://github.com/changedi/mydocker

2，编辑Dockerfile：https://github.com/changedi/mydocker/blob/master/Dockerfile

3，在本地项目中运行docker build <image_name> .，build一个自定义名字的镜像

4，启动这个镜像容器：docker run -d -p 80:80 <image_name>

这样，这个镜像就好了，服务也起来了，后续可以通过docker ps来查看启动的镜像，通过docker stop来停止容器。

我这里解释一下我的Dockerfile：

  1 # Using a compact OS

主要做几件事：

1，拉个操作系统：这里是Ubuntu

2，装工具：curl、jdk、tomcat、nginx，配置环境变量，配置tomcat，配置nginx（tomcat和nginx的配置都是本地搞好，直接add）

3，部署应用（自己的war包），这里我直接利用docker的ADD操作，把git项目中的文件直接add到容器中

参考资料：

1，docker安装 http://www.linuxidc.com/Linux/2014-12/110034.htm

2，dockerfile编写 http://blog.csdn.net/we_shell/article/details/38445979

dump文件包含的内容：

1，全部的对象：类，域，原生值和引用；

2，全部的类：classloader，类名，超类，静态域；

3，GC root：被JVM定义的可触达的对象；

4，线程栈和本地变量：线程的call stack，本地对象每帧的信息。

dump文件不包含内存的分配信息，因此无法查询谁创建了哪个对象这样的信息。

Shallow heap是一个对象占用的内存空间，一个对象需要32或者64bits。

Retained set of X是X在被jvm gc回收后被remove的一组object。

Retained heap of X是在retained set of X中的所有对象的shallow heap size的和。换句话说就是保持X活着需要的内存空间。

通俗的讲，shallow heap是一个对象在内存中的实际空间，而retained heap是一个对象被gc回收后内存释放出来的空间。

这张图可以看懂什么是leading set什么是retained set。

Dominator tree：定义一个对象x dominate 对象y，当每一条从root开始到y的路径都经过x。说白了就是只要有y对象的存活，那么一定会有一个x对象。Dominator tree就是将对象引用图转换成的树形结构。帮助发现在对象间保持alive的依赖，同时也能识别出retained内存的最大的chunk。Immediate dominator x of y是离y最近的dominator。

Dominator tree有几个属性：

1，对象x的子树包含的对象（x dominate的对象集），代表了x的retained set；

2，如果x是y的immediate dominator，那么x的immediate dominator同样dominate y，以此类推；

3，dominate tree中的边不代表对象引用图里对应的边，并非严格的直接的对象引用。

这张图反应了一个对象引用图转换成dominator tree的示例。

Gc root：一个gc根就是一个对象，这个对象从堆外可以访问读取。以下一些方法可以使一个对象成为gc根。

1，System class：被bootstrap或者system类加载器加载的类，比如rt.jar里的java.util.*；

2，JNI local：native代码里的local变量，比如用户定义的JNI代码和JVM的内部代码；

3，JNI global：native代码里的global变量；

4，Thread block：当前活跃的线程block中引用的对象；

5，Thread：已经启动并且没有stop的线程；

6，busy monitor：被调用了wait()或者notify()或者被synchronized同步的对象，如果是synchronized方法，那么静态方法指的类，非静态方法指的是对象；

7，java local：local变量，比如方法的入参和方法内创建的变量；

8，native stack：native代码里的出入参数，比如file/net/IO方法以及反射的参数；

9，finalizable：在一个队列里等待它的finalizer 运行的对象；

10，unfinalized：一个有finalize方法的对象，还没有被finalize，同时也没有进入finalizer队列等待finalize；

11，unreachable：不会被触碰到的对象，在MAT里被标记为root用来retain object，否则是不会在分析中出现的；

12，java stack frame：java栈帧包含了本地变量，当dump被解析时且在preferences里设置过把栈帧当做对象，这时才会产生；

13，unknown：位置的root类型。

接下来是一些获取dump的方法：

1，在oom时dump：JVM参数：-XX:+HeapDumpOnOutOfMemoryError

2，交互式环境下dump：

1）JVM参数：-XX:+HeapDumpOnCtrlBreak

2）用外部tools：jmap -dump:format=b,file=<filename.hprof> <pid>

3）用外部tools：jconsole

4）用外部工具：MAT

5）kill -3 <pid>

6）jstack -l <pid> > <dumpfile>

一些排查方法：

1，通过top consumers查找大对象，可以按照class、classloader和package进行group by；

2，通过immediate dominator找到责任对象，对于快速定位一组对象的持有者非常有用，这个操作直接解决了“谁让这些对象alive”的问题，而不是“谁有这些对象的引用”的问题，更直接高效；

3，运行classloader分析，这个重要性体现在亮点：第一，应用使用不同的classloader加载类，第二，不同classloader加载的类存储在不同的永久代，这理论上也是可以被回收的。当有一个类被不同的classloader加载时，这时要根据各自loader下的instance数量判断哪个loader更重要，从而要把另一个回收掉；

4，分析线程，本身heap dump里包含了thread信息，可以通过MAT来查看threads 的overview和detail，detail中有线程的堆内存信息，也有线程栈，同时还包含了操作系统本地栈。假设不做heap dump，我们检查到系统有问题，如何通过线程的角度来排查呢？首先top -H -p <pid>以线程的模式查看java应用的运行情况，找到占用cpu或者内存大的线程，记录线程id，然后printf %x <tid>转为16进制，再jstack -l <pid> > thread.log把java进程的thread dump出来，从里面找到tid，分析是哪个线程占用了系统资源。

5，分析java容器类，因为java的容器类是最常用来存储对象的，所以理论上发生内存泄露的风险也最高。可以从几个角度来看：1）array填充率查询（填充率fill ratio是数组中非空元素的比例），打印非原生类型数组的填充率频率分布，从而排查系统中array的利用率；2）数组按照size分组查询，打印一个按size分组的直方图；3）collection的填充率查询，ArrayList/HashMap/Hashtable/Properties/Vector/WeakHashMap/ConcurrentHashMap$Segment；4）collection按照size分组直方图；5）查看一个list里的所有对象；6）查看hashmap里的所有对象；7）查看hashset里的对象；8）检查map的碰撞率；9）检查所有只有一个常量的array。

6，分析Finalizer，1）查询finalizer正在处理的对象；2）查询finalizer准备处理的对象；3）直接查看finalizer线程；4）查看finalizer线程的thread local对象。

        几乎每个Java程序员都清楚知道Java的异常和错误机制，无论是在面试过程中，还是在学习中，你看到Exception，无非就是了解一下继承关系、子类、和Error的关系等等。当然这些知识点是基础，那么在实践中，用到了吗？你确定你使用Exception时没有偷懒？我的经验告诉我，良好的使用Exception能让你的程序bug更少，或者至少能保证你的程序更容易被理解和跟踪。

        先回到老的知识点吧——Java的异常机制，我们知道Java里的异常是完全继承Throwable的，正如java doc里注释的，无论你throw的还是JVM throw的，抑或是你想