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.2 利用MAT分析内存堆
DDMS 可以将当前的内存 Dump成一个 hprof格式的文件，MAT 读取这个文件后会给出方便阅读的信息，配合它的查找，对比功能，就可以定位内存泄漏的原因。
· 获取 hprof文件
点击工具栏上的 
· 转换 hprof文件
DDMS Dump 出的文件要经过转换才能被 MAT识别，Android SDK提供了这个工具 hprof-conv (位于 sdk/tools下)
· ./hprof-conv xxx-a.hprof xxx-b.hprof
· 用 MAT打开转换后的 hprof文件
1.3 Histogram 查询
用的最多的功能是 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回收掉的.
1.4 Histogram 对比
为查找内存泄漏，通常需要两个 Dump结果作对比，打开 Navigator History面板，将两个表的 Histogram结果都添加到 Compare Basket中去 :
添加好后，打开 Compare Basket面板，得到结果：
点击右上角的 ! 按钮，将得到比对结果：
注意，上面这个对比结果不利于查找差异，可以调整对比选项：
再把对比的结果排序，就可得到直观的对比结果：
也可以对比两个对象集合，方法与此类似，都是将两个 Dump结果中的对象集合添加到Compare Basket中去对比。找出差异后用 Histogram查询的方法找出 GC Root，定位到具体的某个对象上。
1.5 例子
举例一个典型的分析内存泄漏的过程：
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有差异
· 多使用排序功能，对找出差异很有用
2 内存泄漏的原因分析
总结出来只有一条： 存在无效的引用!
良好的模块设计以及合理使用设计模式有助于解决此问题。
3 Tips
· 使用 android:largeHeap="true"标记 (API Level >= 11)
在 AndroidManifest.xml中的 Application节点中声明即可分配到更大的堆内存, android:largeHeap标记在 Android系统应用中也有广泛的应用 ,比如 Launcher, Browser这些内存大户上均有使用.