jvm类加载机制与使用MAT分析堆内存

jvm通过类加载器，将硬盘上编译好的class文件加载进jvm中。至于它是否可以运行，则有Execution Engine决定

类加载器主要有虚拟机自带的加载器和用户自定义加载器。其中启动类加载器主要加载java中的根类，像Object、Scanner等，这些根类加载时，它们的类加载器为NULL；扩展类加载器主要加载java外部的类（这些外部类存储......jdk\jre\lib\ext中），系统加载器主要加载当前APP中的所有类。

(ps:可以将用户自定义的类，作为jar包，放到......jdk\jre\lib\ext中，这样这个类就变成了扩展类，具体操作：选择“hello world.java”，右键点击Export-》选择jarfile-》next-》选择这个jarFile的存放路径-》finsh,最后将这个jar包放到......jdk\jre\lib\ext中。）

运行结果：

java语言本身不能对操作系统底层进行访问和操作，但是可以通过JNI接口调用其他语言来实现对底层的范文

        打开java的一些抽象类，你会发现其中有很多native的抽象方法。它的作用是融合不同的编程语言为java所用，它的设计初衷是融合c/c++程序，Java诞生的时候是c/C++横行的时候，要想立足，必须有调用C/C++程序，于是就在内存中专门开辟了一块内存区域处理标记Native的代码。它的具体做法是：Native Method Stack中登记Native方法，在Execution Engine执行时加载Native libraries.

       目前该方法使用越来越少了，除非是与硬件有关的应用，比喻通过java程序驱动打印机或者java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用Socket通信，也可以使用WebService等等。

提问：有没有遇到过Stack OverflowError，能不能手写一个这样的代码?

可以这样说，搞懂MAT阿里，百度等一定给你复试机会！！！

使用Eclipse Memory Analyzer分析内存

1.1如何配置？

1.选择安装插件的路径

2.在eclipse上安装插件

3右键选择运行方式-》运行配置，然后按照如下配置

运行之后就出现如下错误

4在文件处点击刷新，就会出现如下文件。

5.点击打来这个文件，一直next就可以了！

DDMS 可以将当前的内存 Dump成一个 hprof格式的文件，MAT 读取这个文件后会给出方便阅读的信息，配合它的查找，对比功能，就可以定位内存泄漏的原因。

·        获取 hprof文件 
点击工具栏上的  按钮，将内存信息保存成文件。 如果是用 MAT Eclipse 插件获取的 Dump文件，则不需要经过转换，Adt会自动进行转换然后打开。

·        转换 hprof文件 
DDMS Dump 出的文件要经过转换才能被 MAT识别，Android SDK提供了这个工具 hprof-conv (位于 sdk/tools下)

·    ./hprof-conv xxx-a.hprof xxx-b.hprof

·        用 MAT打开转换后的 hprof文件 

用的最多的功能是 Histogram,点击 Actions下的 Histogram项将得到 Histogram结果：

它按类名将所有的实例对象列出来，可以点击表头进行排序,在表的第一行可以输入正则表达式来匹配结果 :

在某一项上右键打开菜单选择 list objects ->with incoming refs 将列出该类的实例：

它展示了对象间的引用关系，比如展开后的第一个子项表示这个 HomePage(0x420ca5b0)被HomePageContainer(0x420c9e40)中的 mHomePage属性所引用.

快速找出某个实例没被释放的原因，可以右健 Path to GC Roots-->exclue all phantom/weak/soft etc. reference :

得到的结果是：

从表中可以看出 PreferenceManager -> … ->HomePage这条线路就引用着这个 HomePage实例。用这个方法可以快速找到某个对象的 GC Root,一个存在 GC Root的对象是不会被 GC回收掉的.

为查找内存泄漏，通常需要两个 Dump结果作对比，打开 Navigator History面板，将两个表的 Histogram结果都添加到 Compare Basket中去 :

添加好后，打开 Compare Basket面板，得到结果：

点击右上角的 ! 按钮，将得到比对结果：

注意，上面这个对比结果不利于查找差异，可以调整对比选项：

再把对比的结果排序，就可得到直观的对比结果：

也可以对比两个对象集合，方法与此类似，都是将两个 Dump结果中的对象集合添加到Compare Basket中去对比。找出差异后用 Histogram查询的方法找出 GC Root，定位到具体的某个对象上。

举例一个典型的分析内存泄漏的过程：

1.  使用 Heap查看当前堆大小为 23.00M

2.  添加一个页后堆大小变为 23.40M

3.  将添加的一个页删除，堆大小为 23.40M

4.  多次操作，结果仍相似，说明添加/删除页存在内存泄漏 (也应注意排除其它因素的影响)

5.  Dump 出操作前后的 hprof 文件 (1.hprof,2.hprof)，用 mat打开,并得到 histgram结果

6.  使用 HomePage字段过滤 histgram结果，并列出该类的对象实例列表，看到两个表中的对象集合大小不同，操作后比操作前多出一个 HomePage，说明确实存在泄漏

7.  将两个列表进行对比，找出多出的一个对象，用查找 GC Root的方法找出是谁串起了这条引用线路，定位结束

PS :

·        很多时候堆增大是 Bitmap引起的，Bitmap在 Histogram中的类型是 byte [],对比两个 Histogram中的 byte[]对象就可以找出哪些 Bitmap有差异

·        多使用排序功能，对找出差异很有用

总结出来只有一条： 存在无效的引用! 
良好的模块设计以及合理使用设计模式有助于解决此问题。

·    使用 android:largeHeap="true"标记 (API Level >= 11) 
在 AndroidManifest.xml中的 Application节点中声明即可分配到更大的堆内存, android:largeHeap标记在 Android系统应用中也有广泛的应用 ,比如 Launcher, Browser这些内存大户上均有使用.