java 堆栈分析

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

再次，研究了一个下午的jhat好jmap。从一开始惊呆、懵懂于那样大量而无聊乏味的数据，到现在有那么一点点收货。赶紧记录下来。没办法，悟性太低。。。

C:\Users\Administrator>jps

 Jps

C:\Users\Administrator>jps

 Jps

 HttpServer

C:\Users\Administrator>jmap -dump:file=testJmapa

Dumping heap to C:\Users\Administrator\testJmapa ...

Heap dump file created

C:\Users\Administrator>jhat testJmapa

Reading from testJmapa...

Dump file created Sat Jul  :: CST

Snapshot read, resolving...

Resolving  objects...

Chasing references, expect  dots.

Eliminating duplicate references.

Snapshot resolved.

Started HTTP server on port

Server is ready.

jmap导出内存堆栈的。它能够导出java线程某个时刻的整个内存堆栈信息，记录了每一个类、属性、静态常量等等的信息， —— 唯独不包括类的方法等信息。

jhat 分析jmap导出的内存堆栈。实际上就是提供了一个静态的web server来供查询等等。

首页有：

All Classes (excluding platform)

Package test

class test.HttpServer [0x269bc990]
class test.HttpServer2 [0x269bc7d0]
class test.Test1234 [0x269bc618]

Other Queries

All classes including platform

Show all members of the rootset

Show instance counts for all classes (including platform)

Show instance counts for all classes (excluding platform)

Show heap histogram

Show finalizer summary

Execute Object Query Language (OQL) query

同时提供了oql 这么一种内置的查询语法。

参考http://blog.csdn.net/gtuu0123/article/details/6039474

同时有一些疑问：

1 当我通过jmap导出我一个tomcat 的web 应用的时候，遇到: The VM does not support the attach mechanism 不知道怎么回事

2 为什么会出现0 instances的情况？（在我这个例子中HttpServer继承HttpServe2继承Test1234，名字随便取的）难道说，HttpServer创建的时候引用了HttpServer2和Test1234，所以它们会被加载而计算在All Classes中，但是又因为他们没有被创建实例出来，所以count为0 ？

Instance Counts for All Classes (excluding platform)

1instance of class test.HttpServer
0instances of class test.HttpServer2
0instances of class test.Test1234

3 Heap Histogram 和Instance Counts for All Classes (including platform) 什么区别？后者包含更多的信息排序功能、count、total size(展现为table，如果把表格转换为‘直方’ chart的话，就是Histogram 了吧，理解了Histogram 的含义，一切都好办)，而前者只有count。

4 Show all members of the rootset 为什么这么多内容？当然，这样问的话，显得幼稚。其实我的意思是，什么样的对象可以成为rootset ？怎么静态资源会这么多？为什么每个rootset的路径都那么短（可能是项目不够复杂的原因）？为什么前两者有from、而后面的没有from。。。(很好理解，因为静态资源的locale等是由别的类加载的、我们写的类多数是由Thread加载的，所以有from) 为什么jni、system的ClassLoader为null 其他的没有出现ClassLoader属性。。为什么Java Local References出现了重复的：ServerSocket SocksSocketImpl ReferenceQueue 等出现2次。。。

Java Local References

Java Local Reference (from java.lang.ref.Reference$ReferenceHandler@0x22960a38) :

--> java.lang.ref.Reference$ReferenceHandler@0x22960a38 ( bytes)

Java Local Reference (from java.lang.ref.Finalizer$FinalizerThread@0x22960b38) :

--> java.lang.ref.Finalizer$FinalizerThread@0x22960b38 ( bytes)

Java Local Reference (from java.lang.ref.Reference$ReferenceHandler@0x22960a38) :

--> java.lang.ref.Reference$Lock@0x22960a30 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> test.HttpServer@0x229bfbd0 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> [Ljava.lang.String;@0x229bfbc0 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> java.net.ServerSocket@0x229bfe68 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> test.HttpServer@0x229bfbd0 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> java.net.Socket@0x229c1680 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> java.net.ServerSocket@0x229bfe68 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> java.net.SocksSocketImpl@0x229c16a0 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> java.net.Socket@0x229c1680 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> java.net.ServerSocket@0x229bfe68 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> java.io.FileDescriptor@0x229c14d0 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> java.net.SocksSocketImpl@0x229c16a0 ( bytes)

Java Local Reference (from java.lang.Thread@0x22960790) :

--> java.net.SocksSocketImpl@0x229c1410 ( bytes)

Java Local Reference (from java.lang.ref.Reference$ReferenceHandler@0x22960a38) :

--> java.lang.ref.Reference$Lock@0x22960a30 ( bytes)

Java Local Reference (from java.lang.ref.Finalizer$FinalizerThread@0x22960b38) :

--> java.lang.ref.ReferenceQueue@0x22960b10 ( bytes)

Java Local Reference (from java.lang.ref.Finalizer$FinalizerThread@0x22960b38) :

--> java.lang.ref.ReferenceQueue@0x22960b10 ( bytes)

Java Local Reference (from java.lang.ref.Finalizer$FinalizerThread@0x22960b38) :

--> java.lang.ref.ReferenceQueue$Lock@0x22960b28 ( bytes)

Java Static References 静态资源

Java Local References ———— 个人的项目代码产生的refs

Busy Monitor References

JNI Global References

JNI Local References

System Class References

—— 这样分类的根据是什么？Finalizer Summary 做什么用的？ GC ? 总共出现了多个的ClassLoader呢？有多个实例的对象，怎么判断它们是否由同一个ClassLoader加载的呢？为什么非个人写的class的ClassLoader都是null呢？

总结

写了一个最简单的java程序

public class Test1234 {

　　public String aaa = "asfaf";

    /**

     * @param args

     * @throws Exception

     */

    public static void main(String[] args) throws Exception {

        // TODO Auto-generated method stub

        Thread.sleep();

    }
}

发现，平台需要的类竟然都有

Total of 6476 instances occupying 504439 bytes.

1922instances of class [C
1473instances of class java.lang.String
738instances of class java.util.TreeMap$Entry
367instances of class java.lang.Class
333instances of class [Ljava.lang.Object;
199instances of class java.lang.StringBuilder
185instances of class [Ljava.lang.String;
138instances of class java.io.File

...

class [C	1922	341440
class [B	68	43618
class java.lang.Class	367	27892
class java.lang.String	1473	23568
class java.util.TreeMap$Entry	738	15498
class [Ljava.lang.Object;	333	12800
class [Ljava.lang.String;	185	4812

同时发现Test1234的实例为0

0instances of class test.Test1234

表明它还未被实例化—— 虽然其main方法已经运行了，但是它没有被实例化，所以，其实例变量aaa也没有被创建：

执行oql ：select s.value.toString() from java.lang.String s where /asfaf/(s.value.toString()) ，返回空

改成这样:

package test;

public class Test1234 {

    public String aaa = "asfaf";

    /**

     * @param args

     * @throws Exception

     */

    public static void main(String[] args) throws Exception {

        // TODO Auto-generated method stub

        System.out.println(new Test1234().aaa);

        Thread.sleep();

    }

}

保证了Test1234有被实例化(同时没有被回收),

1instance of class test.Test1234

再次执行上面的oql，有返回了，而且，String对象的个数为

1480instances of class java.lang.String

总实例对象个数发现变化：

Total of 6496 instances occupying 504334 bytes.

再改成：

package test;

public class Test1234 {

    public String aaa = "asfaf";

    /**

     * @param args

     * @throws Exception

     */

    public static void main(String[] args) throws Exception {

        // TODO Auto-generated method stub

        new Test1234().aaa = null;

        Thread.sleep();

    }

}

发现：

1474instances of class java.lang.String

Total of 6479 instances occupying 504476 bytes.

执行同样的oql，发现还是有返回，说明，虽然aaa被赋值为null，但是还是没有被那么快的回收。。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

关于oql

发现其实它也没什么太多作用，无非就是查询堆中类的发布、赋值情况， —— 可以查询登录密码是否包含其中有效的内存中，从而说明其密码没加密？

除此之外呢？。。。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

看了别的文章，感觉还是 Eclipse Memory Analyzer （Tool）（简称MAT）好用，因为mat 是可视化的。。

Mat的优势，不仅仅在于其可视化，

http://chenxy.blog.51cto.com/729966/759221

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

带着问题学技术：

给你一个dump出来的bin文件，

1 如何分析出其当前最耗时间的方法调用，为什么花那么多时间

2 哪个方法调用的次数最多，为什么

3 哪个类最占资源—— 一般是String 或者 char[]/byte[]，除次之外，要注意哪些类的count/size是非常大的—— 可能程序写的不好，就很占资源了。。

4 哪个线程最忙，最占时间，

5 哪个线程最频繁的被启停，就是说启动后执行很短时间，很快又结束

6 是否存在定时的任务线程

7 gc占用了多少时间

8 gc的影响

9 major gc 和minil gc的发生情况，为什么发生—— 是否有异常，换句话说，异常情况下gc是怎么样的

关于jvm：

1 具体有哪些后台线程，分别什么作用，是否可以去掉

2 各个进程的工作机制是什么。。

3 爱上

作为web程序

1 吞吐量如何—— 即处理request的能力（响应速度，返回时间，最大限制）怎么样

2 是否安全—— 是否经得起各种攻击。。

3 设计的是否足够好—— 是否容易维护

正文

All Classes (excluding platform)

Package test

Other Queries

All classes including platform

Show all members of the rootset

Show instance counts for all classes (including platform)

Show instance counts for all classes (excluding platform)

Show heap histogram

Show finalizer summary

Execute Object Query Language (OQL) query

Instance Counts for All Classes (excluding platform)

Total of 6476 instances occupying 504439 bytes.

Total of 6496 instances occupying 504334 bytes.

Total of 6479 instances occupying 504476 bytes.

相关阅读

前端网站设计模式，前端网站设计模式分析

面向对象类图分析，面向对象分析及应用

面向对象分析实验原理，面向对象分析的核心在于

it项目管理特点分析，it项目管理最佳历程

redis分布式锁怎么分析，redis分布式锁原理面试

面向对象系统案例，面向对象分析及应用

工程施工项目管理背景，工程施工项目管理背景分析

go语言分析数据实例，go语言数据分析

目录[+]

All Classes (excluding platform)

Package test

Other Queries All classes including platform Show all members of the rootset Show instance counts for all classes (including platform) Show instance counts for all classes (excluding platform) Show heap histogram Show finalizer summary Execute Object Query Language (OQL) query

Instance Counts for All Classes (excluding platform)

Total of 6476 instances occupying 504439 bytes.

Total of 6496 instances occupying 504334 bytes.

Total of 6479 instances occupying 504476 bytes.

相关阅读

前端网站设计模式，前端网站设计模式分析

面向对象类图分析，面向对象分析及应用

面向对象分析实验原理，面向对象分析的核心在于

it项目管理特点分析，it项目管理最佳历程

redis分布式锁怎么分析，redis分布式锁原理面试

面向对象系统案例，面向对象分析及应用

工程施工项目管理背景，工程施工项目管理背景分析

go语言分析数据实例，go语言 数据分析

目录[+]

Other Queries

All classes including platform

Show all members of the rootset

Show instance counts for all classes (including platform)

Show instance counts for all classes (excluding platform)

Show heap histogram

Show finalizer summary

Execute Object Query Language (OQL) query

go语言分析数据实例，go语言数据分析