java程序运行时的内存空间，按照虚拟机规范有下面几项：
（1）程序计数器
指示下条命令执行地址。当然是线程私有，不然线程怎么能并行的起来。 不重要，占内存很小，忽略不计。
（2）方法区
这个名字很让我迷惑。这里面装的其实是程序运行需要的类文件，常量，静态变量等。作用容易明白。
程序运行时，执行代码先得装入内存，当然java好像是在第一次用到时才加载，这样可以避免装入无用的类，节省内存。
在HosSpot上，方法区现今和永久代是同一个区域。我就这么理解了，虽然作者解释说其实这两者根本不是同一个概念。
概念暂时不大关心，垃圾回收是实实在在工作中用到的。
（3）本地方法栈
存储Native本地方法中用到的局部变量表和操作数栈，动态链接，方法出口等。作用和（4）中无区别，而且在HotSpot上本地方法栈与java虚拟机栈是合二为一的。
（4）Java虚拟机栈
线程私有
存储java方法中用到的局部变量表和操作数栈，动态链接，方法出口等。
在实际工作中会遇到栈内存溢出，StackOverflowError，不过以我的经验，如果出现栈溢出，绝大多数都是死循环递归造成的。
（5）堆
堆在各线程见是共享的。
这个是用的最多的。有好多人甚至以为java运行的需要的内存就只有这个，果果-Xmx可以指定堆可分配的最大值。-Xms指定堆最小分配。
如果-Xms堆不够用时，会自动扩展，当扩展到-Xmx的值，仍然不够，就内存溢出了。OutOfMemoryError。
理论上所有的对象实例和数组都是在堆上分配的，但是JIT编译器可以聪明的做很多事情，也许有些对象的使用范围是局限在某些方法中的，这样就可以在栈上分配，
毕竟栈上分配的内存管理要容易的多，用完即抛，不需要交给垃圾回收器来处理。
当然，写代码的人最好有个谱，什么时候该局部变量，什么时候需要类变量，把自己写的破代码全交给编译器去吭哧吭哧优化，一方面它不能完全优化的完美，
另一方面也占用cpu时间（哎，有感而发，破代码见得太多了）
JVM内存详解
1 本机内存介绍
1.1 硬件限制
1.2 操作系统和虚拟内存
1.2.1 虚拟内存可增加可用内存空间， 但是可能引起性能问题
1.2.2 内核空间和用户空间
2 内存耗尽时现象
当Java 堆耗尽时，Java 应用程序很难正常运行，因为Java 应用程序必须通过分配对象来完成工作。只要Java 堆被填满，就会出现糟糕的GC 性能并抛出表示Java 堆被填满的OutOfMemoryError。
相反，一旦Java运行时开始运行并且应用程序处于稳定状态，它可以在本机堆完全耗尽之后继续正常运行。不一定会发生奇怪的行为，因为需要分配本机内存的操作比需要分配Java 堆的操作少得多。但一些常见操作还是会报错：启动线程、加载类以及执行某种类型的网络和文件I/O。
3 如何占用本机内存
3.1 java堆
Java 堆是分配了对象的内存区域。
堆的大小可以在Java 命令行使用 -Xmx 和 -Xms 选项来控制（mx 表示堆的最大大小，ms 表示初始大小）。
Java堆占用的本机内存为-Xmx，未被使用的部分为保留内存，保留内存不会分配给其他程序使用；
对于维护Java 堆的内存管理系统，需要更多本机内存来维护它的状态。例如行垃圾收集。
3.2 垃圾收集
3.3 即时（JIT）编译
JIT 编译器在运行时编译Java 字节码来优化本机可执行代码。这极大地提高了Java 运行时的速度，并且支持Java 应用程序以与本机代码相当的速度运行。
但JIT 编译器的输入（字节码）和输出（可执行代码）必须也存储在本机内存中。
3.4 类和类加载器
存储类的方式取决于具体实现。Sun JDK 使用永久生成（permanent generation，PermGen）堆区域。Java 5 的IBM 实现会为每个类加载器分配本机内存块，并将类数据存储在其中。
从最基本的层面来看，使用更多的类将需要使用更多内存。
Java运行时可以卸载类来回收空间，但是只有在非常严酷的条件下才会这样做。不能卸载单个类，而是卸载类加载器，随其加载的所有类都会被卸载。只有在以下情况下才能卸载类加载器：
Java 堆不包含对表示该类加载器的 java.lang.ClassLoader 对象的引用。
Java 堆不包含对表示类加载器加载的类的任何 java.lang.Class 对象的引用。
在Java 堆上，该类加载器加载的任何类的所有对象都不再存活（被引用）。
需要注意的是，Java 运行时为所有Java 应用程序创建的3 个默认类加载器（bootstrap、extension 和 application ）都不可能满足这些条件，因此，任何系统类（比如 java.lang.String）或通过应用程序类加载器加载的任何应用程序类都不能在运行时释放。
3.5 JNI
JNI 应用程序可能通过3 种方式增加Java 运行时的本机内存占用：
JNI 应用程序的本机代码被编译到共享库中，或编译为加载到进程地址空间中的可执行文件。大型本机应用程序可能仅仅加载就会占用大量进程地址空间。
本机代码必须与Java 运行时共享地址空间。任何本机代码分配或本机代码执行的内存映射都会耗用Java 运行时的内存。
某些JNI 函数可能在它们的常规操作中使用本机内存。GetTypeArrayElements 和GetTypeArrayRegion 函数可以将Java堆数据复制到本机内存缓冲区中，以供本机代码使用。是否复制数据依赖于运行时实现。（IBM Developer Kit for Java 5.0 和更高版本会进行本机复制）。
通过这种方式访问大量Java 堆数据可能会使用大量本机堆
3.6 NIO
直接bytebuffer会操作本机内存；
3.7 线程
线程的堆栈空间、线程本地存储（thread-local storage）和内部数据结构会占用本机内存。
堆栈大小因Java 实现和架构的不同而不同。一些实现支持为Java 线程指定堆栈大小，其范围通常在256KB 到756KB 之间。
4 调试方法和技术
4.1 检查java堆
JavaCore文件、heapdump文件；
4.2 检查本机堆
Windows 提供的PerfMon 工具；
Linux 使用命令行工具（比如 ps、top 和 pmap）能够显示应用程序的本机内存占用情况。配合使用GCMV，进行长时间跟踪后的分析。
由于JVM 前期阶段的本机内存增长而耗尽本机内存，以及内存使用随负载增加而增加，这些都是尝试在可用空间中做太多事情的例子。在这些场景中，您的选择是：
减少本机内存使用。缩小Java 堆大小是一个好的开端。
限制本机内存使用。如果您的本机内存随负载增加而增加，可以采取某种方式限制负载或为负载分配的资源。
增加可用地址空间。这可以通过以下方式实现：调优您的操作系统（例如，在Windows 上使用/3GB 开关增加用户空间，或者在Linux 上使用庞大的内核空间），更换平台（Linux 通常拥有比Windows 更多的用户空间），或者 转移到64 位操作系统。
4.3 是什么在使用本机内存
根据您的Java 设置，将会使用多少本机内存。根据以下指南粗略估算一下：
Java 堆占用的内存至少为-Xmx 值。
每个Java 线程需要堆栈空间。堆栈空间因实现不同而异，但是如果使用默认设置，每个线程至多会占用756KB 本机内存。
直接 ByteBuffer 至少会占用提供给allocate() 例程的内存值。
UMDH 支持就地 调试Windows 上本机内存泄漏，在Linux 上，您可能需要进行一些传统的调试，而不是依赖工具来解决问题。下面是一些建议的调试步骤：
提取测试案例。生成一个独立环境，您需要能够在该环境中再现本机内存泄漏。这将使调试更加简单。
尽可能缩小测试案例。尝试禁用函数来确定是哪些代码路径导致了本机内存泄漏。如果您拥有自己的JNI 库，可以尝试一次禁用一个来确定是哪个库导致了内存泄漏。
缩小Java 堆大小。Java 堆可能是进程的虚拟地址空间的最大使用者。通过减小Java 堆，可以将更多空间提供给本机内存的其他使用者。
关联本机进程大小。一旦您获得了本机内存随时间的使用情况，可以将其与应用程序工作负载和GC 数据比较。如果泄漏程度与负载级别成正比，则意味着泄漏是由每个事务或操作路径上的某个实体引起的。如果当进行垃圾收集时，本机进程大小显著减小，这意味着您没遇到内存泄漏，您拥有的是具有本机支持的对象组合（比如直接 ByteBuffer）。通过缩小Java 堆大小（从而迫使垃圾收集更频繁地发生），或者在一个对象缓存中管理对象（而不是依赖于垃圾收集器来清理对象），您可以减少本机支持对象持有的内存量。
5 消除限制
更改为64位，但是64位可能引入对象膨胀的问题；
必须关注物理内存是否满足Java程序使用，一旦物理内存不足，发生频繁的与虚拟内存交换，会严重影响性能。
内存溢出：对于整个应用程序来说，ＪＶＭ内存空间，已经没有多余的空间分配给新的对象。所以就发生内存溢出。
内存泄露：在应用的整个生命周期内，某个对象一直存在，且对象占用的内存空间越来越大，最终导致ＪＶＭ内存泄露，
比如：缓存的应用，如果不设置上限的话，缓存的容量可能会一直增长。
静态集合引用，如果该集合存放了无数个对象，随着时间的推移也有可能使容量无限制的增长，最终导致ＪＶＭ内存泄露。
内存泄露，是应用程序中的某个对象长时间的存活，并且占用空间不断增长，最终导致内存泄露。
是对象分配后，长时间的容量增长。
内存溢出，是针对整个应用程序的所有对象的分配空间不足，会造成内存溢出。
内存泄漏
内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。内存泄漏与许多其他问题有着相似的症状，并且通常情况下只能由那些可以获得程序源代码的程序员才可以分析出来。然而，有不少人习惯于把任何不需要的内存使用的增加描述为内存泄漏，即使严格意义上来说这是不准确的。
一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。
内存泄漏可以分为4类：
1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。
简单点： 内存泄漏就是忘记释放使用完毕的内存，让下次使用有一定风险。
内存溢出就是一定的内存空间不能装下所有的需要存放的数据，造成内存数据溢出。
主要从以下几部分来说明，关于内存和内存泄露、溢出的概念，区分内存泄露和内存溢出；内存的区域划分，了解GC回收机制；重点关注如何去监控和发现内存问题；此外分析出问题还要如何解决内存问题。
下面就开始本篇的内容：
第一部分 概念
众所周知，java中的内存由java虚拟机自己去管理的，他不像C++需要自己去释放。笼统地去讲，java的内存分配分为两个部分，一个是数据堆，一个是栈。程序在运行的时候一般分配数据堆，把局部的临时的变量都放进去，生命周期和进程有关系。但是如果程序员声明了static的变量，就直接在栈中运行的，进程销毁了，不一定会销毁static变量。
另外为了保证java内存不会溢出，java中有垃圾回收机制。 System.gc()即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。
而其中，内存溢出就是你要求分配的java虚拟机内存超出了系统能给你的，系统不能满足需求，于是产生溢出。
内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问,该块已分配出来的内存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐无内存使用，就会溢出。
第二部分 原理
JAVA垃圾回收及对内存区划分
在Java虚拟机规范中，提及了如下几种类型的内存空间：
◇ 栈内存（Stack）：每个线程私有的。
◇ 堆内存（Heap）：所有线程公用的。
◇ 方法区（Method Area）：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。
◇ 原生方法栈（Native Method Stack）：主要用于JNI中的原生代码，平时很少涉及。
而Java的使用的是堆内存，java堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，“垃圾回收”也是主要是和堆内存（Heap）有关。
垃圾回收的概念就是JAVA虚拟机（JVM）回收那些不再被引用的对象内存的过程。一般我们认为正在被引用的对象状态为“alive”,而没有被应用或者取不到引用属性的对象状态为“dead”。垃圾回收是一个释放处于”dead”状态的对象的内存的过程。而垃圾回收的规则和算法被动态的作用于应用运行当中，自动回收。
JVM的垃圾回收器采用的是一种分代（generational ）回收策略，用较高的频率对年轻的对象(young generation)进行扫描和回收，这种叫做minor collection，而对老对象(old generation)的检查回收频率要低很多，称为major collection。这样就不需要每次GC都将内存中所有对象都检查一遍，这种策略有利于实时观察和回收。
（Sun JVM 1.3 有两种最基本的内存收集方式：一种称为copying或scavenge，将所有仍然生存的对象搬到另外一块内存后，整块内存就可回收。这种方法有效率，但需要有一定的空闲内存，拷贝也有开销。这种方法用于minor collection。另外一种称为mark-compact，将活着的对象标记出来，然后搬迁到一起连成大块的内存，其他内存就可以回收了。这种方法不需要占用额外的空间，但速度相对慢一些。这种方法用于major collection. ）
一些对象被创建出来只是拥有短暂的生命周期，比如 iterators 和本地变量。另外一些对象被创建是拥有很长的生命周期，比如持久化对象等。
垃圾回收器的分代策略是把内存区划分为几个代，然后为每个代分配一到多个内存区块。当其中一个代用完了分配给他的内存后，JVM会在分配的内存区内执行一个局部的GC（也可以叫minor collection）操作，为了回收处于“dead”状态的对象所占用的内存。局部GC通常要比Full GC快很多。
JVM定义了两个代，年轻代（yong generation）（有时称为“nursery”托儿所）和老年代(old generation)。年轻代包括 “Eden space（伊甸园）”和两个“survivor spaces”。虚拟内存初始化的时候会把所有对象都分配到 Eden space，并且大部分对象也会在该区域被释放。 当进行 minor GC的时候，VM会把剩下的没有释放的对象从Eden space移动到其中一个survivor spaces当中。此外，VM也会把那些长期存活在survivor spaces 里的对象移动到 老生代的“tenured” space中。当 tenured generation 被填满后，就会产生Full GC，Full GC会相对比较慢因为回收的内容包括了所有的 live状态的对象。pemanet generation这个代包括了所有java虚拟机自身使用的相对比较稳定的数据对象，比如类和对象方法等。
关于代的划分，可以从下图中获得一个概况：
第三部分 总结
内存溢出主要是由于代码编写时对某些方法、类应用不合理，或者没有预估到临时对象会占用很大内存量，或者把过多的数据放入JVM缓存，或者性能压力大导致消息堆积而占用内存，以至于在性能测试时，生成庞大数量的临时对象，GC时没有做出有效回收甚至根本就不能回收，造成内存空间不足，内存溢出。
如果编码之前，对内存使用量进行预估，对放在内存中的数据进行评估，保证有用的信息尽快释放，无用的信息能够被GC回收，这样在一定程度上是可以避免内存溢出问题的。
分类： JNI2011-09-27 03:10 1142人阅读 评论(0) 收藏 举报
JNI，Java Native Interface，是 native code 的编程接口。JNI 使 Java 代码程序可以与 native code 交互——在 Java 程序中调用 native code；在 native code 中嵌入 Java 虚拟机调用 Java 的代码。
JNI 编程在软件开发中运用广泛，其优势可以归结为以下几点：
1 利用 native code 的平台相关性，在平台相关的编程中彰显优势。
2 对 native code 的代码重用。
3 native code 底层操作，更加高效。
然而任何事物都具有两面性，JNI 编程也同样如此。程序员在使用 JNI 时应当认识到 JNI 编程中如下的几点弊端，扬长避短，才可以写出更加完善、高性能的代码：
4 从 Java 环境到 native code 的上下文切换耗时、低效。
5 JNI 编程，如果操作不当，可能引起 Java 虚拟机的崩溃。
6 JNI 编程，如果操作不当，可能引起内存泄漏。
JAVA 编程中的内存泄漏，从泄漏的内存位置角度可以分为两种：JVM 中 Java Heap 的内存泄漏；JVM 内存中 native memory 的内存泄漏。
Java 对象存储在 JVM 进程空间中的 Java Heap 中，Java Heap 可以在 JVM 运行过程中动态变化。如果 Java 对象越来越多，占据 Java Heap 的空间也越来越大，JVM 会在运行时扩充 Java Heap 的容量。如果 Java Heap 容量扩充到上限，并且在 GC 后仍然没有足够空间分配新的 Java 对象，便会抛出 out of memory 异常，导致 JVM 进程崩溃。
Java Heap 中 out of memory 异常的出现有两种原因——①程序过于庞大，致使过多 Java 对象的同时存在；②程序编写的错误导致 Java Heap 内存泄漏。
多种原因可能导致 Java Heap 内存泄漏。JNI 编程错误也可能导致 Java Heap 的内存泄漏。
从操作系统角度看，JVM 在运行时和其它进程没有本质区别。在系统级别上，它们具有同样的调度机制，同样的内存分配方式，同样的内存格局。
JVM 进程空间中，Java Heap 以外的内存空间称为 JVM 的 native memory。进程的很多资源都是存储在 JVM 的 native memory 中，例如载入的代码映像，线程的堆栈，线程的管理控制块，JVM 的静态数据、全局数据等等。也包括 JNI 程序中 native code 分配到的资源。
在 JVM 运行中，多数进程资源从 native memory 中动态分配。当越来越多的资源在 native memory 中分配，占据越来越多 native memory 空间并且达到 native memory 上限时，JVM 会抛出异常，使 JVM 进程异常退出。而此时 Java Heap 往往还没有达到上限。
多种原因可能导致 JVM 的 native memory 内存泄漏。例如 JVM 在运行中过多的线程被创建，并且在同时运行。JVM 为线程分配的资源就可能耗尽 native memory 的容量。
JNI 编程错误也可能导致 native memory 的内存泄漏。对这个话题的讨论是本文的重点。
JNI 编程实现了 native code 和 Java 程序的交互，因此 JNI 代码编程既遵循 native code 编程语言的编程规则，同时也遵守 JNI 编程的文档规范。在内存管理方面，native code 编程语言本身的内存管理机制依然要遵循，同时也要考虑 JNI 编程的内存管理。
本章简单概括 JNI 编程中显而易见的内存泄漏。从 native code 编程语言自身的内存管理，和 JNI 规范附加的内存管理两方面进行阐述。
JNI 编程首先是一门具体的编程语言，或者 C 语言，或者 C++，或者汇编，或者其它 native 的编程语言。每门编程语言环境都实现了自身的内存管理机制。因此，JNI 程序开发者要遵循 native 语言本身的内存管理机制，避免造成内存泄漏。以 C 语言为例，当用 malloc() 在进程堆中动态分配内存时，JNI 程序在使用完后，应当调用 free() 将内存释放。总之，所有在 native 语言编程中应当注意的内存泄漏规则，在 JNI 编程中依然适应。
Native 语言本身引入的内存泄漏会造成 native memory 的内存，严重情况下会造成 native memory 的 out of memory。
JNI 编程还要同时遵循 JNI 的规范标准，JVM 附加了 JNI 编程特有的内存管理机制。
JNI 中的 Local Reference 只在 native method 执行时存在，当 native method 执行完后自动失效。这种自动失效，使得对 Local Reference 的使用相对简单，native method 执行完后，它们所引用的 Java 对象的 reference count 会相应减 1。不会造成 Java Heap 中 Java 对象的内存泄漏。
而 Global Reference 对 Java 对象的引用一直有效，因此它们引用的 Java 对象会一直存在 Java Heap 中。程序员在使用 Global Reference 时，需要仔细维护对 Global Reference 的使用。如果一定要使用 Global Reference，务必确保在不用的时候删除。就像在 C 语言中，调用 malloc() 动态分配一块内存之后，调用 free() 释放一样。否则，Global Reference 引用的 Java 对象将永远停留在 Java Heap 中，造成 Java Heap 的内存泄漏。
JNI 编程中潜在的内存泄漏——对 LocalReference 的深入理解
Local Reference 在 native method 执行完成后，会自动被释放，似乎不会造成任何的内存泄漏。但这是错误的。对 Local Reference 的理解不够，会造成潜在的内存泄漏。
本章重点阐述 Local Reference 使用不当可能引发的内存泄漏。引入两个错误实例，也是 JNI 程序员容易忽视的错误；在此基础上介绍 Local Reference 表，对比 native method 中的局部变量和 JNI Local Reference 的不同，使读者深入理解 JNI Local Reference 的实质；最后为 JNI 程序员提出应该如何正确合理使用 JNI Local Reference，以避免内存泄漏。
在某些情况下，我们可能需要在 native method 里面创建大量的 JNI Local Reference。这样可能导致 native memory 的内存泄漏，如果在 native method 返回之前 native memory 已经被用光，就会导致 native memory 的 out of memory。
在代码清单 1 里，我们循环执行 count 次，JNI function NewStringUTF() 在每次循环中从 Java Heap 中创建一个 String 对象，str 是 Java Heap 传给 JNI native method 的 Local Reference，每次循环中新创建的 String 对象覆盖上次循环中 str 的内容。str 似乎一直在引用到一个 String 对象。整个运行过程中，我们看似只创建一个 Local Reference。
执行代码清单 1 的程序，第一部分为 Java 代码，nativeMethod(int i) 中，输入参数设定循环的次数。第二部分为 JNI 代码，用 C 语言实现了 nativeMethod(int i)。
|
Java 代码部分 class TestLocalReference { private native void nativeMethod(int i); public static void main(String args[]) { TestLocalReference c = new TestLocalReference(); //call the jni native method c.nativeMethod(1000000); } static { //load the jni library System.loadLibrary("StaticMethodCall"); } } JNI 代码，nativeMethod(int i) 的 C 语言实现 #include<stdio.h> #include<jni.h> #include"TestLocalReference.h" JNIEXPORT void JNICALL Java_TestLocalReference_nativeMethod (JNIEnv * env, jobject obj, jint count) { jint i = 0; jstring str; for(; i<count; i++) str = (*env)->NewStringUTF(env, "0"); } 运行结果 JVMCI161: FATAL ERROR in native method: Out of memory when expanding local ref table beyond capacity at TestLocalReference.nativeMethod(Native Method) at TestLocalReference.main(TestLocalReference.java:9) |
运行结果证明，JVM 运行异常终止，原因是创建了过多的 Local Reference，从而导致 out of memory。实际上，nativeMethod 在运行中创建了越来越多的 JNI Local Reference，而不是看似的始终只有一个。过多的 Local Reference，导致了 JNI 内部的 JNI Local Reference 表内存溢出。
实例 2 是实例 1 的变种，Java 代码未作修改，但是 nativeMethod(int i) 的 C 语言实现稍作修改。在 JNI 的 native method 中实现的 utility 函数中创建 Java 的 String 对象。utility 函数只建立一个 String 对象，返回给调用函数，但是 utility 函数对调用者的使用情况是未知的，每个函数都可能调用它，并且同一函数可能调用它多次。在实例 2 中，nativeMethod 在循环中调用 count 次，utility 函数在创建一个 String 对象后即返回，并且会有一个退栈过程，似乎所创建的 Local Reference 会在退栈时被删除掉，所以应该不会有很多 Local Reference 被创建。实际运行结果并非如此。
|
Java 代码部分参考实例 1，未做任何修改。 JNI 代码，nativeMethod(int i) 的 C 语言实现 #include<stdio.h> #include<jni.h> #include"TestLocalReference.h" jstring CreateStringUTF(JNIEnv * env) { return (*env)->NewStringUTF(env, "0"); } JNIEXPORT void JNICALL Java_TestLocalReference_nativeMethod (JNIEnv * env, jobject obj, jint count) { jint i = 0; for(; i<count; i++) { str = CreateStringUTF(env); } } 运行结果 JVMCI161: FATAL ERROR in native method: Out of memory when expanding local ref table beyond capacity at TestLocalReference.nativeMethod(Native Method) at TestLocalReference.main(TestLocalReference.java:9) |
运行结果证明，实例 2 的结果与实例 1 的完全相同。过多的 Local Reference 被创建，仍然导致了 JNI 内部的 JNI Local Reference 表内存溢出。实际上，在 utility 函数 CreateStringUTF(JNIEnv * env)
执行完成后的退栈过程中，创建的 Local Reference 并没有像 native code 中的局部变量那样被删除，而是继续在 Local Reference 表中存在，并且有效。Local Reference 和局部变量有着本质的区别。
Java JNI 的文档规范只描述了 JNI Local Reference 是什么（存在的目的），以及应该怎么使用 Local Reference（开放的接口规范）。但是对 Java 虚拟机中 JNI Local Reference 的实现并没有约束，不同的 Java 虚拟机有不同的实现机制。这样的好处是，不依赖于具体的 JVM 实现，有好的可移植性；并且开发简单，规定了“应该怎么做、怎么用”。但是弊端是初级开发者往往看不到本质，“不知道为什么这样做”。对 Local Reference 没有深层的理解，就会在编程过程中无意识的犯错。
Local Reference 和 Local Reference 表
理解 Local Reference 表的存在是理解 JNI Local Reference 的关键。
JNI Local Reference 的生命期是在 native method 的执行期（从 Java 程序切换到 native code 环境时开始创建，或者在 native method 执行时调用 JNI function 创建），在 native method 执行完毕切换回 Java 程序时，所有 JNI Local Reference 被删除，生命期结束（调用 JNI function 可以提前结束其生命期）。
实际上，每当线程从 Java 环境切换到 native code 上下文时（J2N），JVM 会分配一块内存，创建一个 Local Reference 表，这个表用来存放本次 native method 执行中创建的所有的 Local Reference。每当在 native code 中引用到一个 Java 对象时，JVM 就会在这个表中创建一个 Local Reference。比如，实例 1 中我们调用 NewStringUTF() 在 Java Heap 中创建一个 String 对象后，在 Local Reference 表中就会相应新增一个 Local Reference。
图 1. Local Reference 表、Local Reference 和 Java 对象的关系
图 1 中：
⑴运行 native method 的线程的堆栈记录着 Local Reference 表的内存位置（指针 p）。
⑵ Local Reference 表中存放 JNI Local Reference，实现 Local Reference 到 Java 对象的映射。
⑶ native method 代码间接访问 Java 对象（java obj1，java obj2）。通过指针 p 定位相应的 Local Reference 的位置，然后通过相应的 Local Reference 映射到 Java 对象。
⑷当 native method 引用一个 Java 对象时，会在 Local Reference 表中创建一个新 Local Reference。在 Local Reference 结构中写入内容，实现 Local Reference 到 Java 对象的映射。
⑸ native method 调用 DeleteLocalRef() 释放某个 JNI Local Reference 时，首先通过指针 p 定位相应的 Local Reference 在 Local Ref 表中的位置，然后从 Local Ref 表中删除该 Local Reference，也就取消了对相应 Java 对象的引用（Ref count 减 1）。
⑹当越来越多的 Local Reference 被创建，这些 Local Reference 会在 Local Ref 表中占据越来越多内存。当 Local Reference 太多以至于 Local Ref 表的空间被用光，JVM 会抛出异常，从而导致 JVM 的崩溃。
Local Ref 不是 native code 的局部变量
很多人会误将 JNI 中的 Local Reference 理解为 Native Code 的局部变量。这是错误的。
Native Code 的局部变量和 Local Reference 是完全不同的，区别可以总结为：
⑴局部变量存储在线程堆栈中，而 Local Reference 存储在 Local Ref 表中。
⑵局部变量在函数退栈后被删除，而 Local Reference 在调用 DeleteLocalRef() 后才会从 Local Ref 表中删除，并且失效，或者在整个 Native Method 执行结束后被删除。
⑶可以在代码中直接访问局部变量，而 Local Reference 的内容无法在代码中直接访问，必须通过 JNI function 间接访问。JNI function 实现了对 Local Reference 的间接访问，JNI function 的内部实现依赖于具体 JVM。
代码清单 1 中 str = (*env)->NewStringUTF(env, "0");
str 是 jstring 类型的局部变量。Local Ref 表中会新创建一个 Local Reference，引用到 NewStringUTF(env, "0") 在 Java Heap 中新建的 String 对象。如图 2 所示：
图 2 中，str 是局部变量，在 native method 堆栈中。Local Ref3 是新创建的 Local Reference，在 Local Ref 表中，引用新创建的 String 对象。JNI 通过 str 和指针 p 间接定位 Local Ref3，但 p 和 Local Ref3 对 JNI 程序员不可见。
Local Reference 导致内存泄漏
在以上论述基础上，我们通过分析错误实例 1 和实例 2，来分析 Local Reference 可能导致的内存泄漏，加深对 Local Reference 的深层理解。
分析错误实例 1：
局部变量 str 在每次循环中都被重新赋值，间接指向最新创建的 Local Reference，前面创建的 Local Reference 一直保留在 Local Ref 表中。
在实例 1 执行完第 i 次循环后，内存布局如图 3：
继续执行完第 i+1 次循环后，内存布局发生变化，如图 4：
图 4 中，局部变量 str 被赋新值，间接指向了 Local Ref i+1。在 native method 运行过程中，我们已经无法释放 Local Ref i 占用的内存，以及 Local Ref i 所引用的第 i 个 string 对象所占据的 Java Heap 内存。所以，native memory 中 Local Ref i 被泄漏，Java Heap 中创建的第 i 个 string 对象被泄漏了。
也就是说在循环中，前面创建的所有 i 个 Local Reference 都泄漏了 native memory 的内存，创建的所有 i 个 string 对象都泄漏了 Java Heap 的内存。
直到 native memory 执行完毕，返回到 Java 程序时（N2J），这些泄漏的内存才会被释放，但是 Local Reference 表所分配到的内存往往很小，在很多情况下 N2J 之前可能已经引发严重内存泄漏，导致 Local Reference 表的内存耗尽，使 JVM 崩溃，例如错误实例 1。
分析错误实例 2：
实例 2 与实例 1 相似，虽然每次循环中调用工具函数 CreateStringUTF(env) 来创建对象，但是在 CreateStringUTF(env) 返回退栈过程中，只是局部变量被删除，而每次调用创建的 Local Reference 仍然存在 Local Ref 表中，并且有效引用到每个新创建的 string 对象。str 局部变量在每次循环中被赋新值。
这样的内存泄漏是潜在的，但是这样的错误在 JNI 程序员编程过程中却经常出现。通常情况，在触发 out of memory 之前，native method 已经执行完毕，切换回 Java 环境，所有 Local Reference 被删除，问题也就没有显露出来。但是某些情况下就会引发 out of memory，导致实例 1 和实例 2 中的 JVM 崩溃。
因此，在 JNI 编程时，正确控制 JNI Local Reference 的生命期。如果需要创建过多的 Local Reference，那么在对被引用的 Java 对象操作结束后，需要调用 JNI function（如 DeleteLocalRef()），及时将 JNI Local Reference 从 Local Ref 表中删除，以避免潜在的内存泄漏。
本文阐述了 JNI 编程可能引发的内存泄漏，JNI 编程既可能引发 Java Heap 的内存泄漏，也可能引发 native memory 的内存泄漏，严重的情况可能使 JVM 运行异常终止。JNI 软件开发人员在编程中，应当考虑以下几点，避免内存泄漏：
· native code 本身的内存管理机制依然要遵循。
· 使用 Global reference 时，当 native code 不再需要访问 Global reference 时，应当调用 JNI 函数 DeleteGlobalRef() 删除 Global reference 和它引用的 Java 对象。Global reference 管理不当会导致 Java Heap 的内存泄漏。
· 透彻理解 Local reference，区分 Local reference 和 native code 的局部变量，避免混淆两者所引起的 native memory 的内存泄漏。
· 使用 Local reference 时，如果 Local reference 引用了大的 Java 对象，当不再需要访问 Local reference 时，应当调用 JNI 函数 DeleteLocalRef() 删除 Local reference，从而也断开对 Java 对象的引用。这样可以避免 Java Heap 的 out of memory。
· 使用 Local reference 时，如果在 native method 执行期间会创建大量的 Local reference，当不再需要访问 Local reference 时，应当调用 JNI 函数 DeleteLocalRef() 删除 Local reference。Local reference 表空间有限，这样可以避免 Local reference 表的内存溢出，避免 native memory 的 out of memory。
· 严格遵循 Java JNI 规范书中的使用规则。
Java 堆（每个 Java 对象在其中分配）是您在编写 Java 应用程序时使用最频繁的内存区域。JVM 设计用于将我们与主机的特性隔离，所以将内存当作堆来考虑再正常不过了。您一定遇到过 Java 堆 OutOfMemoryError ， 它可能是由于对象泄漏造成的，也可能是因为堆的大小不足以存储所有数据，您也可能了解这些场景的一些调试技巧。但是随着您的 Java 应用程序处理越来越多的数据和越来越多的并发负载，您可能就会遇到无法使用常规技巧进行修复的 OutOfMemoryError 。 在一些场景中，即使 java 堆未满，也会抛出错误。当这类场景发生时，您需要理解 Java 运行时环境（Java Runtime Environment，JRE）内部到底发生了什么。
Java 应用程序在 Java 运行时的虚拟化环境中运行，但是运行时本身是使用 C 之类的语言编写的本机程序，它也会耗用本机资源，包括本机内存 。本机内存是可用于运行时进程的内存，它与 Java 应用程序使用的 java 堆内存不同。每种虚拟化资源（包括 Java 堆和 Java 线程）都必须存储在本机内存中，虚拟机在运行时使用的数据也是如此。这意味着主机的硬件和操作系统施加在本机内存上的限制会影响到 Java 应用程序的性能。
本系列文章共分两篇，讨论不同平台上的相应话题。本文是其中一篇。在这两篇文章中，您将了解什么是本机内存，Java 运行时如何使用它，本机内存耗尽之后会发生什么情况，以及如何调试本机 OutOfMemoryError 。本文介绍 Windows 和 Linux 平台上的这一主题，不会介绍任何特定的运行时实现。
本机进程遇到的许多限制都是由硬件造成的，而与操作系统没有关系。每台计算机都有一个处理器和一些随机存取存储器（RAM），后者也称为物理 内存。处理器将数据流解释为要执行的指令，它拥有一个或多个处理单元，用于执行整数和浮点运算以及更高级的计算。处理器具有许多寄存器 —— 常快速的内存元素，用作被执行的计算的工作存储，寄存器大小决定了一次计算可使用的最大数值。
处理器通过内存总线连接到物理内存。物理地址（处理器用于索引物理 RAM 的地址）的大小限制了可以寻址的内存。例如，一个 16 位物理地址可以寻址 0x0000 到 0xFFFF 的内存地址，这个地址范围包括 2^16 = 65536 个惟一的内存位置。如果每个地址引用一个存储字节，那么一个 16 位物理地址将允许处理器寻址 64KB 内存。
处理器被描述为特定数量的数据位。这通常指的是寄存器大小，但是也存在例外，比如 32 位 390 指的是物理地址大小。对于桌面和服务器平台，这个数字为 31、32 或 64；对于嵌入式设备和微处理器，这个数字可能小至 4。物理地址大小可以与寄存器带宽一样大，也可以比它大或小。如果在适当的操作系统上运行，大部分 64 位处理器可以运行 32 位程序。
表 1 列出了一些流行的 Linux 和 Windows 架构，以及它们的寄存器和物理地址大小：
|
架构 |
寄存器带宽（位） |
物理地址大小（位） |
|
（现代）Intel® x86 |
32 |
32 |
|
x86 64 |
64 |
目前为 48 位（以后将会增大） |
|
PPC64 |
64 |
在 POWER 5 上为 50 位 |
|
390 31 位 |
32 |
31 |
|
390 64 位 |
64 |
64 |
如果您编写无需操作系统，直接在处理器上运行的应用程序，您可以使用处理器可以寻址的所有内存（假设连接到了足够的物理 RAM）。但是要使用多任务和硬件抽象等特性，几乎所有人都会使用某种类型的操作系统来运行他们的程序。
在 Windows 和 Linux 等多任务操作系统中，有多个程序在使用系统资源。需要为每个程序分配物理内存区域来在其中运行。可以设计这样一个操作系统：每个程序直接使用物理内存，并 且可以可靠地仅使用分配给它的内存。一些嵌入式操作系统以这种方式工作，但是这在包含多个未经过集中测试的应用程序的环境中是不切实际的，因为任何程序都 可能破坏其他程序或者操作系统本身的内存。
虚拟内存 允许多个进程共享物理内存，而且不会破坏彼此的数据。在具有虚拟内存的操作系统（比如 Windows、Linux 和许多其他操作系统）中，每个程序都拥有自己的虚拟地址空间 —— 一个逻辑地址区域，其大小由该系统上的地址大小规定（所以，桌面和服务器平台的虚拟地址空间为 31、32 或 64 位）。进程的虚拟地址空间中的区域可被映射到物理内存、文件或任何其他可寻址存储。当数据未使用时，操作系统可以在物理内存与一个交换区域 （Windows 上的页面文件 或者 Linux 上的交换分区 ）之间移动它，以实现对物理内存的最佳利用率。当一个程序 尝试使用虚拟地址访问内存时，操作系统连同片上硬件会将该虚拟地址映射到物理位置，这个位置可以是物理 RAM、一个文件或页面文件/交换分区。如果一个内存区域被移动到交换空间，那么它将在被使用之前加载回物理内存中。图 1 展示了虚拟内存如何将进程地址空间区域映射到共享资源：
图 1. 虚拟内存将进程地址空间映射到物理资源
程序的每个实例以进程 的形式运行。在 Linux 和 Windows 上，进程是一个由受操作系统控制的资源（比如文件和套接字信息）、一个典型的虚拟地址空间（在某些架构上不止一个）和至少一个执行线程构成的集合。
虚拟地址空间大小可能比处理器的物理地址大小更小。32 位 Intel x86 最初拥有的 32 位物理地址仅允许处理器寻址 4GB 存储空间。后来，添加了一种称为物理地址扩展（Physical Address Extension，PAE）的特性，将物理地址大小扩大到了 36 位，允许安装或寻址至多 64GB RAM。PAE 允许操作系统将 32 位的 4GB 虚拟地址空间映射到一个较大的物理地址范围，但是它不允许每个进程拥有 64GB 虚拟地址空间。这意味着如果您将大于 4GB 的内存放入 32 位 Intel 服务器中，您将无法将所有内存直接映射到一个单一进程中。
地址窗口扩展（Address Windowing Extension）特性允许 Windows 进程将其 32 位地址空间的一部分作为滑动窗口映射到较大的内存区域中。Linux 使用类似的技术将内存区域映射到虚拟地址空间中。这意味着尽管您无法直接引用大于 4GB 的内存，但您仍然可以使用较大的内存区域。
尽管每个进程都有其自己的地址空间，但程序通常无法使用所有这些空间。地址空间被划分为用户空间 和内核空间 。 内核是主要的操作系统程序，包含用于连接计算机硬件、调度程序以及提供联网和虚拟内存等服务的逻辑。
作为计算机启动序列的一部分，操作系统内核运行并初始化硬件。一旦内核配置了硬件及其自己的内部状态，第一个用户空间进程就会启动。如果用户 程序需要来自操作系统的服务，它可以执行一种称为系统调用 的操作与内核程序交互，内核程序然后执行该请求。系统调用通常是读取和写入文件、联网和启动新进程等操作所必需的。
当执行系统调用时，内核需要访问其自己的内存和调用进程的内存。因为正在执行当前线程的处理器被配置为使用地址空间映射来为当前进程映射虚拟 地址，所以大部分操作系统将每个进程地址空间的一部分映射到一个通用的内核内存区域。被映射来供内核使用的地址空间部分称为内核空间，其余部分称为用户空 间，可供用户应用程序使用。
内核空间和用户空间之间的平衡关系因操作系统的不同而不同，甚至在运行于不同硬件架构之上的同一操作系统的各个实例间也有所不同。这种平衡通 常是可配置的，可进行调整来为用户应用程序或内核提供更多空间。缩减内核区域可能导致一些问题，比如能够同时登录的用户数量限制或能够运行的进程数量限 制。更小的用户空间意味着应用程序编程人员只能使用更少的内存空间。
默认情况下，32 位 Windows 拥有 2GB 用户空间和 2GB 内核空间。在一些 Windows 版本上，通过向启动配置添加 /3GB 开关并使用 /LARGEADDRESSAWARE 开关重新链接应用程序，可以将这种平衡调整为 3GB 用户空间和 1GB 内核空间。在 32 位 Linux 上，默认设置为 3GB 用户空间和 1GB 内核空间。一些 Linux 分发版提供了一个 hugemem 内核，支持 4GB 用户空间。为了实现这种配置，将进行系统调用时使用的地址空间分配给内核。通过这种方式增加用户空间会减慢系统调用，因为每次进行系统调用时，操作系统必 须在地址空间之间复制数据并重置进程地址-空间映射。图 2 展示了 32 位 Windows 的地址-空间布局：
图 2. 32 位 Windows 的地址-空间布局
图 3 显示了 32 位 Linux 的地址-空间配置：
图 3. 32 位 Linux 的地址-空间布局
31 位 Linux 390 上还使用了一个独立的内核地址空间，其中较小的 2GB 地址空间使对单个地址空间进行划分不太合理，但是，390 架构可以同时使用多个地址空间，而且不会降低性能。
进程空间必须包含程序需要的所有内容，包括程序本身和它使用的共享库（在 Windows 上为 DDL，在 Linux 上为 .so 文件）。共享库不仅会占据空间，使程序无法在其中存储数据，它们还会使地址空间碎片化，减少可作为连续内存块分配的内存。这对于在拥有 3GB 用户空间的 Windows x86 上运行的程序尤为明显。DLL 在构建时设置了首选的加载地址：当加载 DLL 时，它被映射到处于特定位置的地址空间，除非该位置已经被占用，在这种情况下，它会加载到别处。Windows NT 最初设计时设置了 2GB 可用用户空间，这对于要构建来加载接近 2GB 区域的系统库很有用 —— 使大部分用户区域都可供应用程序自由使用。当用户区域扩展到 3GB 时，系统共享库仍然加载接近 2GB 数据（约为用户空间的一半）。尽管总体用户空间为 3GB，但是不可能分配 3GB 大的内存块，因为共享库无法加载这么大的内存。
在 Windows 中使用 /3GB 开关，可以将内核空间减少一半，也就是最初设计的大小。在一些情形下，可能耗尽 1GB 内核空间，使 I/O 变得缓慢，且无法正常创建新的用户会话。尽管 /3GB 开关可能对一些应用程序非常有用，但任何使用它的环境在部署之前都应该进行彻底的负载测试。
本机内存泄漏或过度使用本机内存将导致不同的问题，具体取决于您是耗尽了地址空间还是用完了物理内存。耗尽地址空间通常只会发生在 32 位进程上，因为最大 4GB 的内存很容易分配完。64 位进程具有数百或数千 GB 的用户空间，即使您特意消耗空间也很难耗尽这么大的空间。如果您确实耗尽了 Java 进程的地址空间，那么 Java 运行时可能会出现一些陌生现象，本文稍后将详细讨论。当在进程地址空间比物理内存大的系统上运行时，内存泄漏或过度使用本机内存会迫使操作系统交换后备存 储器来用作本机进程的虚拟地址空间。访问经过交换的内存地址比读取驻留（在物理内存中）的地址慢得多，因为操作系统必须从硬盘驱动器拉取数据。可能会分配 大量内存来用完所有物理内存和所有交换内存（页面空间），在 Linux 上，这将触发内核内存不足（OOM）结束程序，强制结束最消耗内存的进程。在 Windows 上，与地址空间被占满时一样，内存分配将会失败。
同时，如果尝试使用比物理内存大的虚拟内存，显然在进程由于消耗内存太大而被结束之前就会遇到问题。系统将变得异常缓慢，因为它会将大部分时 间用于在内存与交换空间之间来回复制数据。当发生这种情况时，计算机和独立应用程序的性能将变得非常糟糕，从而使用户意识到出现了问题。当 JVM 的 Java 堆被交换出来时，垃圾收集器的性能会变得非常差，应用程序可能被挂起。如果一台机器上同时使用了多个 Java 运行时，那么物理内存必须足够分配给所有 Java 堆。
Java 运行时是一个操作系统进程，它会受到我在上一节中列出的硬件和操作系统局限性的限制。运行时环境提供的功能受一些未知的用户代码驱动，这使得无法预测在每 种情形中运行时环境将需要何种资源。Java 应用程序在托管 Java 环境中执行的每个操作都会潜在地影响提供该环境的运行时的需求。本节描述 Java 应用程序为什么和如何使用本机内存。
Java 堆是分配了对象的内存区域。大多数 Java SE 实现都拥有一个逻辑堆，但是一些专家级 Java 运行时拥有多个堆，比如实现 Java 实时规范（Real Time Specification for Java，RTSJ）的运行时。一个物理堆可被划分为多个逻辑扇区，具体取决于用于管理堆内存的垃圾收集（GC）算法。这些扇区通常实现为连续的本机内存 块，这些内存块受 Java 内存管理器（包含垃圾收集器）控制。
堆的大小可以在 Java 命令行使用 -Xmx 和 -Xms 选项来控制（mx 表示堆的最大大小，ms 表示初始大小）。尽管逻辑堆（经常被使用的内存区域）可以根据堆上的对象数量和在 GC 上花费的时间而增大和缩小，但使用的本机内存大小保持不变，而且由 -Xmx 值（最大堆大小）指定。大部分 GC 算法依赖于被分配为连续的内存块的堆，因此不能在堆需要扩大时分配更多本机内存。所有堆内存必须预先保留。
保留本机内存与分配本机内存不同。当本机内存被保留时，无法使用物理内存或其他存储器作为备用内存。尽管保留地址空间块不会耗尽物理资源，但 会阻止内存被用于其他用途。由保留从未使用的内存导致的泄漏与泄漏分配的内存一样严重。
当使用的堆区域缩小时，一些垃圾收集器会回收堆的一部分（释放堆的后备存储空间），从而减少使用的物理内存。
对于维护 Java 堆的内存管理系统，需要更多本机内存来维护它的状态。当进行垃圾收集时，必须分配数据结构来跟踪空闲存储空间和记录进度。这些数据结构的确切大小和性质因 实现的不同而不同，但许多数据结构都与堆大小成正比。
JIT 编译器在运行时编译 Java 字节码来优化本机可执行代码。这极大地提高了 Java 运行时的速度，并且支持 Java 应用程序以与本机代码相当的速度运行。
字节码编译使用本机内存（使用方式与 gcc 等静态编译器使用内存来运行一样），但 JIT 编译器的输入（字节码）和输出（可执行代码）必须也存储在本机内存中。包含多个经过 JIT 编译的方法的 Java 应用程序会使用比小型应用程序更多的本机内存。
Java 应用程序由一些类组成，这些类定义对象结构和方法逻辑。Java 应用程序也使用 Java 运行时类库（比如 java.lang.String ） 中的类，也可以使用第三方库。这些类需要存储在内存中以备使用。
存储类的方式取决于具体实现。Sun JDK 使用永久生成（permanent generation，PermGen）堆区域。Java 5 的 IBM 实现会为每个类加载器分配本机内存块，并将类数据存储在其中。现代 Java 运行时拥有类共享等技术，这些技术可能需要将共享内存区域映射到地址空间。要理解这些分配机制如何影响您 Java 运行时的本机内存占用，您需要查阅该实现的技术文档。然而，一些普遍的事实会影响所有实现。
从最基本的层面来看，使用更多的类将需要使用更多内存。（这可能意味着您的本机内存使用量会增加，或者您必须明确地重新设置 PermGen 或共享类缓存等区域的大小，以装入所有类）。记住，不仅您的应用程序需要加载到内存中，框架、应用服务器、第三方库以及包含类的 Java 运行时也会按需加载并占用空间。
Java 运行时可以卸载类来回收空间，但是只有在非常严酷的条件下才会这样做。不能卸载单个类，而是卸载类加载器，随其加载的所有类都会被卸载。只有在以下情况下 才能卸载类加载器：
7 Java 堆不包含对表示该类加载器的 java.lang.ClassLoader 对象的引用。
8 Java 堆不包含对表示类加载器加载的类的任何 java.lang.Class 对象的引用。
9 在 Java 堆上，该类加载器加载的任何类的所有对象都不再存活（被引用）。
需要注意的是，Java 运行时为所有 Java 应用程序创建的 3 个默认类加载器（ bootstrap 、extension 和 application ）都不可能满足这些条件，因此，任何系统类（比如 java.lang.String ） 或通过应用程序类加载器加载的任何应用程序类都不能在运行时释放。
即使类加载器适合进行收集，运行时也只会将收集类加载器作为 GC 周期的一部分。一些实现只会在某些 GC 周期中卸载类加载器。
也可能在运行时生成类，而不用释放它。许多 JEE 应用程序使用 JavaServer Pages (JSP) 技术来生成 Web 页面。使用 JSP 会为执行的每个 .jsp 页面生成一个类，并且这些类会在加载它们的类加载器的整个生存期中一直存在 —— 这个生存期通常是 Web 应用程序的生存期。
另一种生成类的常见方法是使用 Java 反射。反射的工作方式因 Java 实现的不同而不同，但 Sun 和 IBM 实现都使用了这种方法，我马上就会讲到。
当使用 java.lang.reflect API 时，Java 运行时必须将一个反射对象（比如 java.lang.reflect.Field ） 的方法连接到被反射到的对象或类。这可以通过使用 Java 本机接口（Java Native Interface，JNI）访问器来完成，这种方法需要的设置很少，但是速度缓慢。也可以在运行时为您想要反射到的每种对象类型动态构建一个类。后一种 方法在设置上更慢，但运行速度更快，非常适合于经常反射到一个特定类的应用程序。
Java 运行时在最初几次反射到一个类时使用 JNI 方法，但当使用了若干次 JNI 方法之后，访问器会膨胀为字节码访问器，这涉及到构建类并通过新的类加载器进行加载。执行多次反射可能导致创建了许多访问器类和类加载器。保持对反射对象 的引用会导致这些类一直存活，并继续占用空间。因为创建字节码访问器非常缓慢，所以 Java 运行时可以缓存这些访问器以备以后使用。一些应用程序和框架还会缓存反射对象，这进一步增加了它们的本机内存占用。
JNI 支持本机代码（使用 C 和 C++ 等本机编译语言编写的应用程序）调用 Java 方法，反之亦然。Java 运行时本身极大地依赖于 JNI 代码来实现类库功能，比如文件和网络 I/O。JNI 应用程序可能通过 3 种方式增加 Java 运行时的本机内存占用：
10 JNI 应用程序的本机代码被编译到共享库中，或编译为加载到进程地址空间中的可执行文件。大型本机应用程序可能仅仅加载就会占用大量进程地址空间。
11 本机代码必须与 Java 运行时共享地址空间。任何本机代码分配或本机代码执行的内存映射都会耗用 Java 运行时的内存。
12 某些 JNI 函数可能在它们的常规操作中使用本机内存。GetType ArrayElements 和 GetType ArrayRegion 函数可以将 Java 堆数据复制到本机内存缓冲区中，以供本机代码使用。是否复制数据依赖于运行时实现。（IBM Developer Kit for Java 5.0 和更高版本会进行本机复制）。通过这种方式访问大量 Java 堆数据可能会使用大量本机堆。
Java 1.4 中添加的新 I/O (NIO) 类引入了一种基于通道和缓冲区来执行 I/O 的新方式。就像 Java 堆上的内存支持 I/O 缓冲区一样，NIO 添加了对直接 ByteBuffer 的支持（使用 java.nio.ByteBuffer.allocateDirect()方法进行分配）， ByteBuffer 受本机内存而不是 Java 堆支持。直接 ByteBuffer 可以直接传递到本机操作系统库函数，以执行 I/O — 这使这些函数在一些场景中要快得多，因为它们可以避免在 Java 堆与本机堆之间复制数据。
对于在何处存储直接 ByteBuffer 数据，很容易产生混淆。应用程序仍然在 Java 堆上使用一个对象来编排 I/O 操作，但持有该数据的缓冲区将保存在本机内存中，Java 堆对象仅包含对本机堆缓冲区的引用。非直接ByteBuffer 将其数据保存在 Java 堆上的 byte[] 数组中。图 4 展示了直接与非直接 ByteBuffer 对象之间的区别：
图 4. 直接与非直接 java.nio.ByteBuffer 的内存拓扑结构
直接 ByteBuffer 对象会自动清理本机缓冲区，但这个过程只能作为 Java 堆 GC 的一部分来执行，因此它们不会自动响应施加在本机堆上的压力。GC 仅在 Java 堆被填满，以至于无法为堆分配请求提供服务时发生，或者在 Java 应用程序中显式请求它发生（不建议采用这种方式，因为这可能导致性能问题）。
发生垃圾收集的情形可能是，本机堆被填满，并且一个或多个直接 ByteBuffers 适合于垃圾收集（并且可以被释放来腾出本机堆的空间），但 Java 堆几乎总是空的，所以不会发生垃圾收集。
应用程序中的每个线程都需要内存来存储器堆栈 （用于在调用函数时持有局部变量并维护状态的内存区域）。每个 Java 线程都需要堆栈空间来运行。根据实现的不同，Java 线程可以分为本机线程和 Java 堆栈。除了堆栈空间，每个线程还需要为线程本地存储（thread-local storage）和内部数据结构提供一些本机内存。
堆栈大小因 Java 实现和架构的不同而不同。一些实现支持为 Java 线程指定堆栈大小，其范围通常在 256KB 到 756KB 之间。
尽管每个线程使用的内存量非常小，但对于拥有数百个线程的应用程序来说，线程堆栈的总内存使用量可能非常大。如果运行的应用程序的线程数量比 可用于处理它们的处理器数量多，效率通常很低，并且可能导致糟糕的性能和更高的内存占用。
Java 运行时善于以不同的方式来处理 Java 堆的耗尽与本机堆的耗尽，但这两种情形具有类似的症状。当 Java 堆耗尽时，Java 应用程序很难正常运行，因为 Java 应用程序必须通过分配对象来完成工作。只要 Java 堆被填满，就会出现糟糕的 GC 性能并抛出表示 Java 堆被填满的 OutOfMemoryError 。
相反，一旦 Java 运行时开始运行并且应用程序处于稳定状态，它可以在本机堆完全耗尽之后继续正常运行。不一定会发生奇怪的行为，因为需要分配本机内存的操作比需要分配 Java 堆的操作少得多。尽管需要本机内存的操作因 JVM 实现不同而异，但也有一些操作很常见：启动线程、加载类以及执行某种类型的网络和文件 I/O。
本机内存不足行为与 Java 堆内存不足行为也不太一样，因为无法对本机堆分配进行单点控制。尽管所有 Java 堆分配都在 Java 内存管理系统控制之下，但任何本机代码（无论其位于 JVM、Java 类库还是应用程序代码中）都可能执行本机内存分配，而且会失败。尝试进行分配的代码然后会处理这种情况，无论设计人员的意图是什么：它可能通过 JNI 接口抛出一个 OutOfMemoryError ，在屏幕上输出一条消息，发生无提示失败并在稍后再试一次，或者执行其他操 作。
缺乏可预测行为意味着无法确定本机内存是否耗尽。相反，您需要使用来自操作系统和 Java 运行时的数据执行诊断。
为了帮助您了解本机内存耗尽如何影响您正使用的 Java 实现，本文的示例代码中包含了一些 Java 程序，用于以不同方式触发本机堆耗尽。这些示例使用通过 C 语言编写的本机库来消耗所有本机地址空间，然后尝试执行一些使用本机内存的操作。提供的示例已经过编译，编译它们的指令包含在示例包的顶级目录下的 README.html 文件中。
com.ibm.jtc.demos.NativeMemoryGlutton 类提供了 gobbleMemory() 方法，它在一个循环中调用 malloc ，直到几乎所有本 机内存都已耗尽。完成任务之后，它通过以下方式输出分配给标准错误的字节数：
|
Allocated 1953546736 bytes of native memory before running out |
针对在 32 位 Windows 上运行的 Sun 和 IBM Java 运行时的每次演示，其输出都已被捕获。提供的二进制文件已在以下操作系统上进行了测试：
13 Linux x86
14 Linux PPC 32
15 Linux 390 31
16 Windows x86
使用以下 Sun Java 运行时版本捕获输出：
|
java version "1.5.0_11" |
使用的 IBM Java 运行时版本为：
|
java version "1.5.0" |
com.ibm.jtc.demos.StartingAThreadUnderNativeStarvation 类尝试在耗尽进程地址空间时启动一个线程。这是发现 Java 进程已耗尽内存的一种常用方式，因为许多应用程序都会在其整个生存期启动线程。
当在 IBM Java 运行时上运行时，StartingAThreadUnderNativeStarvation 演示的输出如下：
|
Allocated 1019394912 bytes of native memory before running out |
调用 java.lang.Thread.start() 来尝试为一个新的操作系统线程分配内存。此尝试会失败并抛出 OutOfMemoryError 。JVMDUMP 行通知用户 Java 运行时已经生成了标准的 OutOfMemoryError 调试数据。
尝试处理第一个 OutOfMemoryError 会导致第二个错误 —— :OutOfMemoryError, ENOMEM error in ZipFile.open 。当本机进程内存耗尽时通常会抛出多个 OutOfMemoryError 。Failed to fork OS thread 可能是在耗尽本机内存时最常见的消息。
本文提供的示例会触发一个 OutOfMemoryError 集群，这比您在自己的应用程序中看到的情况要严重得多。这一定程度上是因为几乎所有本机内存都已被使用，与实际的应用程序不同，使用的内存不会在以后被释 放。在实际应用程序中，当抛出 OutOfMemoryError 时，线程会关闭，并且可能会释放一部分本机内存，以让运行时处理错误。测试案例的这个细微特性还意味着，类库的许多部分（比如安全系统）未被初始化，而且 它们的初始化受尝试处理内存耗尽情形的运行时驱动。在实际应用程序中，您可能会看到显示了很多错误，但您不太可能在一个位置看到所有这些错误。
在 Sun Java 运行时上执行相同的测试案例时，会生成以下控制台输出：
|
Allocated 1953546736 bytes of native memory before running out |
尽管堆栈轨迹和错误消息稍有不同，但其行为在本质上是一样的：本机分配失败并抛出 java.lang.OutOfMemoryError 。 此场景中抛出的 OutOfMemoryError 与由于 Java 堆耗尽而抛出的错误的惟一区别在于消息。
com.ibm.jtc.demos.DirectByteBufferUnderNativeStarvation 类尝试在地址空间耗尽时分配一个直接（也就是受本机支持的）java.nio.ByteBuffer 对象。当在 IBM Java 运行时上运行时，它生成以下输出：
|
Allocated 1019481472 bytes of native memory before running out |
在此场景中，抛出了 OutOfMemoryError ，它会触发默认的错误文档。OutOfMemoryError 到达主线程堆栈的顶部，并在 stderr 上输出。
当在 Sun Java 运行时上运行时，此测试案例生成以下控制台输出：
|
Allocated 1953546760 bytes of native memory before running out |
|
当出现 java.lang.OutOfMemoryError 或看到有关内存不足的错误消息时，要做的第一件事是确定哪种类型的内存被耗尽。最简单的方式是首先检查 Java 堆是否被填满。如果 Java 堆未导致 OutOfMemory 条件，那么您应该分析本机堆使用情况。
检查堆使用情况的方法因 Java 实现不同而异。在 Java 5 和 6 的 IBM 实现上，当抛出 OutOfMemoryError 时会生成一个 javacore 文件来告诉您。javacore 文件通常在 Java 进程的工作目录中生成，以 javacore.日期 .时 间 .pid .txt 的形式命名。如果您在文本编辑器中打开该文件，可以看到以下信息：
|
0SECTION MEMINFO subcomponent dump routine |
这部分信息显示在生成 javacore 时有多少空闲的 Java 堆。注意，显示的值为十六进制格式。如果因为分配条件不满足而抛出了 OutOfMemoryError 异常，则 GC 轨迹部分会显示如下信息：
|
1STGCHTYPE GC History |
J9AllocateObject() returning NULL! 意味着 Java 堆分配例程未成功完成，并且将抛出 OutOfMemoryError 。
也可能由于垃圾收集器运行太频繁（意味着堆被填满了并且 Java 应用程序的运行速度将很慢或停止运行）而抛出 OutOfMemoryError 。 在这种情况下，您可能想要 Heap Space Free 值非常小，GC 轨迹将显示以下消息之一：
|
1STGCHTYPE GC History |
|
1STGCHTYPE GC History |
当 Sun 实现耗尽 Java 堆内存时，它使用异常消息来显示它耗尽的是 Java 堆：
|
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space |
IBM 和 Sun 实现都拥有一个详细的 GC 选项，用于在每个 GC 周期生成显示堆填充情况的跟踪数据。此信息可使用工具（比如 IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer (GCMV)）来分析，以显示 Java 堆是否在增长。
如果您确定内存耗尽情况不是由 Java 堆耗尽引起的，那么下一步就是分析您的本机内存使用情况。
Windows 提供的 PerfMon 工具可用于监控和记录许多操作系统和进程指标，包括本机内存使用。它允许实时跟踪计数器 ，或将其存储在日志文件中以供离线查看。使用 Private Bytes 计数器显示总体地址空间使用情况。如果显示值接近于用户空间的限制（前面已经讨论过，介于 2 到 3GB 之间），您应该会看到本机内存耗尽情况。
Linux 没有类似于 PerfMon 的工具，但是它提供了几个替代工具。命令行工具（比如 ps 、top 和 pmap ）能够显示应用程序的本机内存占用情况。尽管获取进程内存使用情况的实时快照非常有用，但通过记录内存随时间的 使用情况，您能够更好地理解本机内存是如何被使用的。为此，能够采取的一种方式是使用 GCMV。
GCMV 最初编写用于分析冗长的 GC 日志，允许用户在调优垃圾收集器时查看 Java 堆使用情况和 GC 性能的变化。GCMV 后来进行了扩展，支持分析其他数据源，包括 Linux 和 AIX 本机内存数据。GCMV 是作为 IBM Support Assistant (ISA) 的插件发布的。
要使用 GCMV 分析 Linux 本机内存配置文件，您首先必须使用脚本收集本机内存数据。GCMV 的 Linux 本机内存分析器通过根据时间戳隔行扫描的方式，读取 Linux ps 命令的输出。GCMV 提供了一个脚本来帮助以正确形式记录收集数据。要找到该脚本：
· 下载并安装 ISA Version 4（或更高版本），然后安装 GCMV 工具插件。
· 启动 ISA。
· 从菜单栏单击 Help >> Help Contents ，打开 ISA 帮助菜单。
· 在左侧窗格的 Tool:IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer >> Using the Garbage Collection and Memory Visualizer >> Supported Data Types >> Native memory >> Linux native memory 下找到 Linux 本机内存说明。
图 5 显示了该脚本在 ISA 帮助文件中的位置。如果您的帮助文件中没有 GCMV Tool 条目，很可能是因为您没有安装 GCMV 插件。
图 5. Linux 本机内存数据捕获脚本在 ISA 帮助对话框中的位置
GCMV 帮助文件中提供的脚本使用的 ps 命令仅适用于最新的 ps 版本。在一些旧的 Linux 分发版中，帮助文件中的命令将会生成错误信息。要查看您的 Linux 分发版上的行为，可以尝试运行 ps -o pid,vsz=VSZ,rss=RSS。如果您的 ps 版本支持新的命令行参数语法，那么得到的输出将类似于：
|
PID VSZ RSS |
如果您的 ps 版本不支持新语法，得到的输出将类似于：
|
PID VSZ,rss=RSS |
如果您在一个较老的 ps 版本上运行，可以修改本机内存脚本，将
|
ps -p $PID -o pid,vsz=VSZ,rss=RSS |
行替换为
|
ps -p $PID -o pid,vsz,rss |
将帮助面板中的脚本复制到一个文件中（在本例中名为 memscript.sh），找到您想要监控的 Java 进程的进程 ID (PID)（本例中为 1234）并运行：
|
./memscript.sh 1234 > ps.out |
这会把本机内存日志写入到 ps.out 中。要分析内存使用情况：
· 在 ISA 中，从 Launch Activity 下拉菜单选择 Analyze Problem 。
· 选择接近 Analyze Problem 面板顶部的 Tools 标签。
· 选择 IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer .
· 单击接近工具面板底部的 Launch 按钮。
· 单击 Browse 按钮并找到日志文件。单击 OK 启动 GCMV。
一旦您拥有了本机内存随时间的使用情况的配置文件，您需要确定是存在本机内存泄漏，还是在尝试在可用空间中做太多事情。即使对于运行良好的 Java 应用程序，其本机内存占用也不是从启动开始就一成不变的。一些 Java 运行时系统（尤其是 JIT 编译器和类加载器）会不断初始化，这会消耗本机内存。初始化增加的内存将高居不下，但是如果初始本机内存占用接近于地址空间的限制，那么仅这个前期阶段就 足以导致本机内存耗尽。图 6 给出了一个 Java 压力测试示例中的 GCMV 本机内存使用情况，其中突出显示了前期阶段。
图 6. GCMV 的 Linux 本机内存使用示例，其中显示了前期阶段
本机内存占用也可能应工作负载不同而异。如果您的应用程序创建了较多进程来处理传入的工作负载，或者根据应用于系统的负载量按比例分配本机存 储（比如直接 ByteBuffer ），则可能由于负载过高而耗尽本机内存。
由于 JVM 前期阶段的本机内存增长而耗尽本机内存，以及内存使用随负载增加而增加，这些都是尝试在可用空间中做太多事情的例子。在这些场景中，您的选择是：
17 减少本机内存使用。 缩小 Java 堆大小是一个好的开端。
18 限制本机内存使用。 如果您的本机内存随负载增加而增加，可以采取某种方式限制负载或为负载分配的资源。
19 增加可用地址空间。 这可以通过以下方式实现：调优您的操作系统（例如，在 Windows 上使用 /3GB 开关增加用户空间，或者在 Linux 上使用庞大的内核空间），更换平台（Linux 通常拥有比 Windows 更多的用户空间）。
一种实际的本机内存泄漏表现为本机堆的持续增长，这些内存不会在移除负载或运行垃圾收集器时减少。内存泄漏程度因负载不同而不同，但泄漏的总 内存不会下降。泄漏的内存不可能被引用，因此它可以被交换出去，并保持被交换出去的状态。
当遇到内存泄漏时，您的选择很有限。您可以增加用户空间（这样就会有更多的空间供泄漏），但这仅能延缓最终的内存耗尽。如果您拥有足够的物理 内存和地址空间，并且会在进程地址空间耗尽之前重启应用程序，那么可以允许地址空间继续泄漏。
一旦确定本机内存被耗尽，下一个逻辑问题是：是什么在使用这些内存？这个问题很难回答，因为在默认情况下，Windows 和 Linux 不会存储关于分配给特定内存块的代码路径的信息。
当尝试理解本机内存都到哪里去了时，您的第一步是粗略估算一下，根据您的 Java 设置，将会使用多少本机内存。如果没有对 JVM 工作机制的深入知识，很难得出精确的值，但您可以根据以下指南粗略估算一下：
20 Java 堆占用的内存至少为 -Xmx 值。
21 每个 Java 线程需要堆栈空间。堆栈空间因实现不同而异，但是如果使用默认设置，每个线程至多会占用 756KB 本机内存。
22 直接 ByteBuffer 至少会占用提供给 allocate() 例程的内存值。
如果总数比您的最大用户空间少得多，那么您很可能不安全。Java 运行时中的许多其他组件可能会分配大量内存，进而引起问题。但是，如果您的初步估算值与最大用户空间很接近，则可能存在本机内存问题。如果您怀疑存在本机 内存泄漏，或者想要准确了解内存都到哪里去了，使用一些工具将有所帮助。
Microsoft 提供了 UMDH（用户模式转储堆）和 LeakDiag 工具来在 Windows 上调试本机内存增长。这两个工具的机制相同：记录特定内存区域被分配给了哪个代码路径，并提供一种方式来定位所分配的内存不会在以后被释放的代码部分。我建 议您查阅文章 “Umdhtools.exe：如何使用 Umdh.exe 发现 Windows 上的内存泄漏”。在本文中，我将主要讨论 UMDH 在分析存在泄漏的 JNI 应用程序时的输出。
本文包含一个名为 LeakyJNIApp 的 Java 应用程序，它循环调用一个 JNI 方法来泄漏本机内存。UMDH 命令获取当前的本机堆的快照，以及分配每个内存区域的代码路径的本机堆栈轨迹快照。通过获取两个快照，并使用 UMDH 来分析差异，您会得到两个快照之间的堆增长报告。
对于 LeakyJNIApp ，差异文件包含以下信息：
|
// _NT_SYMBOL_PATH set by default to C:/WINDOWS/symbols |
重要的一行是 + 412192 ( 1031943 - 619751) 963 allocs BackTrace00468 。它显示一个 backtrace 进行了 963 次分配，而且分配的内存都没有释放 — 总共使用了 412192 字节内存。通过查看一个快照文件，您可以将BackTrace00468 与有意义的代码路径关联起来。在第一个快照文件中搜索 BackTrace00468 ，可以找到如下信息：
|
000000AD bytes in 0x1 allocations (@ 0x00000031 + 0x0000001F) by: BackTrace00468 |
这显示内存泄漏来自 Java_com_ibm_jtc_demos_LeakyJNIApp_nativeMethod 函数中的 leakyjniapp.dll 模块。
在编写本文时，Linux 没有类似于 UMDH 或 LeakDiag 的工具。但在 Linux 上仍然可以采用许多方式来调试本机内存泄漏。Linux 上提供的许多内存调试器可分为以下类别：
23 预处理器级别。 这些工具需要将一个头文件编译到被测试的源代码中。可以使用这些工具之一重新编译您自己的 JNI 库，以跟踪您代码中的本机内存泄漏。除非您拥有 Java 运行时本身的源代码，否则这种方法无法在 JVM 中发现内存泄漏（甚至很难在随后将这类工具编译到 JVM 等大型项目中，并且编译非常耗时）。Dmalloc 就是这类工具的一个例子。
24 链接程序级别。 这些工具将被测试的二进制文件链接到一个调试库。再一次，尽管这对个别 JNI 库是可行的，但不推荐将其用于整个 Java 运行时，因为运行时供应商不太可能支持您运行修改的二进制文件。Ccmalloc 是这类工具的一个例子。
25 运行时链接程序级别。 这些工具使用 LD_PRELOAD 环境变量预先加载一个库，这个库将标准内存例程替换为指定的版本。这些工具不需要重新编译或重新链接源代码，但其中许多工具与 Java 运行时不太兼容。Java 运行时是一个复杂的系统，可以以非常规的方式使用内存和线程，这通常会干扰或破坏这类工具。您可以试验一下，看看是否有一些工具适用于您的场景。 NJAMD 是这类工具的一个例子。
26 基于模拟程序。 Valgrind memcheck 工具是这类内存调试器的惟一例子。它模拟底层处理器，与 Java 运行时模拟 JVM 的方式类似。可以在 Valgrind 下运行 Java 应用程序，但是会有严重的性能影响（速度会减慢 10 到 30 倍），这意味着难以通过这种方式运行大型、复杂的 Java 应用程序。Valgrind 目前可在 Linux x86、AMD64、PPC 32 和 PPC 64 上使用。如果您使用 Valgrind，请在使用它之前尝试使用最小的测试案例来将减轻性能问题（如果可能，最好移除整个 Java 运行时）。
对于能够容忍这种性能开销的简单场景，Valgrind memcheck 是最简单且用户友好的免费工具。它能够为泄漏内存的代码路径提供完整的堆栈轨迹，提供方式与 Windows 上的 UMDH 相同。
LeakyJNIApp 非常简单，能够在 Valgrind 下运行。当模拟的程序结束时，Valgrind memcheck 工具能够输出泄漏的内存的汇总信息。默认情况下，LeakyJNIApp 程序会一直运行，要使其在固定时期之后关闭，可以将运行时间（以秒为单位）作为惟一的命令行参数进行传递。
一些 Java 运行时以非常规的方式使用线程堆栈和处理器寄存器，这可能使一些调试工具产生混淆，这些工具要求本机程序遵从寄存器使用和堆栈结构的标准约定。当使用 Valgrind 调试存在内存泄漏的 JNI 应用程序时，您可以发现许多与内存使用相关的警告，并且一些线程堆栈看起来很奇怪，这是由 Java 运行时在内部构造其数据的方式所导致的，不用担心。
要使用 Valgrind memcheck 工具跟踪 LeakyJNIApp ， （在一行上）使用以下命令：
|
valgrind --trace-children=yes --leak-check=full |
--trace-children=yes 选项使 Valgrind 跟踪由 Java 启动器启动的任何进程。一些 Java 启动器版本会重新执行其本身（它们从头重新启动其本身，再次设置环境变量来改变行为）。如果您未指定 --trace-children ， 您将不能跟踪实际的 Java 运行时。
--leak-check=full 选项请求在代码运行结束时输出对泄漏的代码区域的完整堆栈轨迹，而不只是汇总内存的状态。
当该命令运行时，Valgrind 输出许多警告和错误（在此环境中，其中大部分都是无意义的），最后按泄漏的内存量升序输出存在泄漏的调用堆栈。在 Linux x86 上，针对 LeakyJNIApp 的 Valgrind 输出的汇总部分结尾如下：
|
==20494== 8,192 bytes in 8 blocks are possibly lost in loss record 36 of 45 |
堆栈的第二行显示内存是由 com.ibm.jtc.demos.LeakyJNIApp.nativeMethod() 方法泄漏的。
也可以使用一些专用调试应用程序来调试本机内存泄漏。随着时间的推移，会有更多工具（包括开源和专用的）被开发出来，这对于研究当前技术的发 展现状很有帮助。
就目前而言，使用免费工具调试 Linux 上的本机内存泄漏比在 Windows 上完成相同的事情更具挑战性。UMDH 支持就地 调试 Windows 上本机内存泄漏，在 Linux 上，您可能需要进行一些传统的调试，而不是依赖工具来解决问题。下面是一些建议的调试步骤：
27 提取测试案例。 生成一个独立环境，您需要能够在该环境中再现本机内存泄漏。这将使调试更加简单。
28 尽可能缩小测试案例。 尝试禁用函数来确定是哪些代码路径导致了本机内存泄漏。如果您拥有自己的 JNI 库，可以尝试一次禁用一个来确定是哪个库导致了内存泄漏。
29 缩小 Java 堆大小。 Java 堆可能是进程的虚拟地址空间的最大使用者。通过减小 Java 堆，可以将更多空间提供给本机内存的其他使用者。
30 关联本机进程大小。 一旦您获得了本机内存随时间的使用情况，可以将其与应用程序工作负载和 GC 数据比较。如果泄漏程度与负载级别成正比，则意味着泄漏是由每个事务或操作路径上的某个实体引起的。如果当进行垃圾收集时，本机进程大小显著减小，这意味 着您没遇到内存泄漏，您拥有的是具有本机支持的对象组合（比如直接 ByteBuffer ）。通过缩小 Java 堆大小（从而迫使垃圾收集更频繁地发生），或者在一个对象缓存中管理对象（而不是依赖于垃圾收集器来清理对象），您可以减少本机支持对象持有的内存量。
如果您确定内存泄漏或增长来自于 Java 运行时本身，您可能需要联系运行时供应商来进一步调试。
使用 32 位 Java 运行时很容易遇到本机内存耗尽的情况，因为地址空间相对较小。32 位操作系统提供的 2 到 4GB 用户空间通常小于系统附带的物理内存量，而且现代的数据密集型应用程序很容易耗尽可用空间。
如果 32 位地址空间不够您的应用程序使用，您可以通过移动到 64 位 Java 运行时来获得更多用户空间。如果您运行的是 64 位操作系统，那么 64 位 Java 运行时将能够满足海量 Java 堆的需求，还会减少与地址空间相关的问题。表 2 列出了 64 位操作系统上目前可用的用户空间。
|
操作系统 |
默认用户空间大小 |
|
Windows x86-64 |
8192GB |
|
Windows Itanium |
7152GB |
|
Linux x86-64 |
500GB |
|
Linux PPC64 |
1648GB |
|
Linux 390 64 |
4EB |
然而，移动到 64 位并不是所有本机内存问题的通用解决方案，您仍然需要足够的物理内存来持有所有数据。如果物理内存不够 Java 运行时使用，运行时性能将变得非常糟，因为操作系统不得不在内存与交换空间之间来回复制 Java 运行时数据。出于相同原因，移动到 64 位也不是内存泄漏永恒的解决方案，您只是提供了更多空间来供泄漏，这只会延缓您不得不重启应用程序的时间。
无法在 64 位运行时中使用 32 位本机代码。任何本机代码（JNI 库、JVM Tool Interface [JVMTI]、JVM Profiling Interface [JVMPI] 以及 JVM Debug Interface [JVMDI] 代理）都必须编译为 64 位。64 位运行时的性能也可能比相同硬件上对应的 32 位运行时更慢。64 位运行时使用 64 位指针（本机地址引用），因此，64 位运行时上的 Java 对象会占用比 32 位运行时上包含相同数据的对象更多的空间。更大的对象意味着要使用更大的堆来持有相同的数据量，同时保持类似的 GC 性能，这使操作系统和硬件缓存效率更低。令人惊讶的是，更大的 Java 堆并不一定意味着更长的 GC 暂停时间，因为堆上的活动数据量可能不会增加，并且一些 GC 算法在使用更大的堆时效率更高。
一些现代 Java 运行时包含减轻 64 位 “对象膨胀” 和改善性能的技术。这些功能在 64 位运行时上使用更短的引用。这在 IBM 实现中称为压缩引用 ，而在 Sun 实现中称为压缩 oop 。
对 Java 运行时性能的比较研究不属于本文讨论范围，但是如果您正在考虑移动到 64 位，尽早测试应用程序以理解其执行原理会很有帮助。由于更改地址大小会影响到 Java 堆，所以您将需要在新架构上重新调优您的 GC 设置，而不是仅仅移植现有设置。
在设计和运行大型 Java 应用程序时，理解本机内存至关重要，但是这一点通常被忽略，因为它与复杂的硬件和操作系统细节密切相关，Java 运行时的目的正是帮助我们规避这些细节。JRE 是一个本机进程，它必须在由这些纷繁复杂的细节定义的环境中工作。要从 Java 应用程序中获得最佳的性能，您必须理解应用程序如何影响 Java 运行时的本机内存使用。
耗尽本机内存与耗尽 Java 堆很相似，但它需要不同的工具集来调试和解决。修复本机内存问题的关键在于理解运行您的 Java 应用程序的硬件和操作系统施加的限制，并将其与操作系统工具知识结合起来，监控本机内存使用。通过这种方法，您将能够解决 Java 应用程序产生的一些非常棘手的问题。
译序：Java 的内存泄漏，这不是一个新话题。Jim Patrick 的这篇文章早在 2001 年就写出来了。但这并不意味着 Java 的内存泄漏是一个过时了的甚至不重要的话题。相反，Java 的内存泄漏应当是每一个关心程序健壮性、高性能的程序员所必须了解的知识。
本文将揭示什么时候需要关注内存泄漏以及如何进行防止。
摘要：Java 程序里也存在内存泄漏？当然。和流行的看法相反，内存管理仍然是 Java 编程时应该考虑的事情。在这篇文章里，你会了解到是什么原因导致了 Java 内存泄漏以及什么时候需要对这些泄漏进行关注。你也将会学到一个快速实用的课程以应对自己项目中的内存泄漏。梦痕文学网 http://www.menghen.net/
Java 程序里的内存泄漏是如何表现的
大多数程序员都知道使用类似于 Java 的编程语言的好处之一就是他们无需再为内存的分配和释放所担心了。你只需要简单地创建对象，当它们不再为程序所需要时 Java 会自行通过一个被称为垃圾收集的机制将其移除。这个过程意味着 Java 已经解决了困扰其他编程语言的一个棘手的问题 -- 可怕的内存泄漏。果真是这样的吗？
在进行深入讨论之前，让我们先回顾一下垃圾收集是如何进行实际工作的。垃圾收集器的工作就是找到程序不再需要的对象并在当它们不再被访问或引用时将它们移除掉。垃圾收集器从贯穿整个程序生命周期的类这个根节点开始，扫描所有引用到的节点。在遍历节点时，它跟踪那些被活跃引用着的对象。那些不再被引用的对象就满足了垃圾回收的条件。当这些对象被移除时被它们占用的内存资源会交还给 Java 虚拟机(JVM)。
因此 Java 代码的确不需要程序员负责内存管理的清理工作，它自行对不再使用的对象进行垃圾收集。然而，需要记住的是，垃圾收集的关键在于一个对象在不再被引用时才被统计为不再使用。下图对这一概念进行了说明。
上图表示在一个 Java 程序执行时具有不同的生命周期的两个类。类 A 首先被实例化，它存在的时间比较长，几乎贯穿整个进程的生命周期。在某个时间点，类 B 被创建，类 A 添加了一个对这个新建类的引用。我们假设类 B 是某个用于显示并返回用户指令的用户界面部件。尽管类 B 不再被使用，如果类 A 对类 B 的引用未被清除，类 B 将继续存在并占据内存空间，即使下一次垃圾收集被执行。
什么时候需要注意内存泄漏？
如果在你的程序执行一段时间之后遇到 java.lang.OutOfMemoryError 的话，内存泄漏无疑是最值得怀疑的。除了这种明显的情况之外，什么时候需要考虑内存泄漏？完美主义的程序员会回答说所有的内存泄漏都需要进行审查和更改。然而，在跳到这一结论之前还需要考虑其他几点因素，包括程序的生命周期以及内存泄漏的大小。
考虑一下在一个程序的生命周期里垃圾收集器可能从未执行的情况。无法保证什么时候 JVM 会调用垃圾收集 -- 即使程序显式调用 System.gc()。通常情况下，垃圾收集器不会自动运行，直到程序需要比目前可用内存还要多的内存。此时，JVM 会首先尝试调用垃圾收集器以获取更多可用内存。如果这个尝试仍旧不能够释放出足够的资源，JVM 将会从操作系统获取更多内存，直到达到所允许内存的最大值。
举个例子来说，一个小型的 Java 应用程序，用来显示一些简单的配置修改的用户界面元素，出现了内存泄漏。垃圾收集器可能在程序关闭之前都不会被调用到，因为 JVM 可能总是有足够的内存来创建程序所需要的所有对象。因此，在这种情况下，即便是一些已死对象在程序运行的时候仍旧占据着内存，但这并不影响实际应用。
如果开发中的 Java 代码将以每天 24 小时运行在服务器上，这时内存泄漏将会比上面的那个配置工具程序要明显的多了。即便是代码中最小的内存泄漏，在持续运行的情况下最终也将耗尽所有可用内存。
相反的情况下，即使一个程序只是短暂存活，却分配了大量临时对象(或者少量的占用大量内存的对象)，在这些对象不再需要时没有取消引用，这样的 Java 代码也会达到内存限制。
最后一个值得注意的问题是，不必过于担心(Java 程序所造成的)内存泄漏。Java 内存泄漏不应该被认为是像其他语言中所发生的那样危险，比如 C++ 的内存丢失将永远不会返回给操作系统。Java 应用程序中，我们把不再需要的却占据着内存资源的对象都交给 JVM。所以在理论上来说，一旦 Java 程序和它的 JVM 关闭掉，所有分配的内存都将归还给操作系统。
如何断定程序具有内存泄漏
查看一个运行在 Windows NT 平台上的 Java 程序是否具有内存泄漏，你可以简单地在程序运行的时候去观察任务管理器中的内存设置。然而，在观察一些运行中的 Java 程序之后，你会发现，它们跟本地应用程序相比使用更多内存。我开发过的一些 Java 项目会启用 10 到 20 MB 的系统内存。与这个数字相比，本地的操作系统自带的 Windows Explorer 程序使用到 5 MB。
另外一个关于 Java 程序的内存使用要注意的是典型的运行在 IBM JDK1.1.8 JVM 上的程序似乎在其运行时不断吞噬了越来越多的系统内存。程序似乎永远不会返回一些内存给操作系统，直到一个非常大的物理内存分配给它。这会不会就是内存泄漏的迹象？
要明白是怎么回事，我们需要熟悉 JVM 是如何将系统内存使用作自己的堆的。在运行 java.exe 时，你可以使用一些特定的选项来控制垃圾收集的堆的启动容量和最大容量(分别是 -ms 和 -mx)。Sun 的 JDK 1.1.8 默认使用 1 MB 的启动设置和 16 MB 的最大设置。IBM JDK 1.1.8 默认使用机器物理内存容量的一半作为最大设置。这些内存设置对 JVM 发生内存溢出时的做法具有直接影响，这时 JVM 可能会继续增长堆内存，而不是等待一个垃圾回收的结束。
因此为了寻找并最终消除内存泄漏，我们需要比任务监视程序更好的工具。当你想检测内存泄漏的时候内存调试程序(参见下文的参考资料)可以派上用场了。这些程序通常会给你关于堆内存里对象的数量、每个对象实例的个数以及对象使用中的内存等一些信息。此外，它们还会提供很有用的视图，这些视图可以显示每个对象的引用和引用者，以便你跟踪内存漏洞的来源。
接下来，我将展示如何使用 Sitraka Software 的 JProbe 调试工具来检测和消除内存泄漏，希望会对你就如何部署这些工具并成功消除内存泄漏产生一些启发。
一个内存泄漏的例子
这个示例主要展示了我们部门开发的一个商业版应用的一个问题，这个问题在 JDK 1.1.8 上工作了几个小时后被测试人员找出来。这个 Java 应用程序的相关代码和包是由几个不同团队的程序员开发出来的。程序里出现的内存泄漏的原因，我怀疑，是由一些没有真正理解其他(团队)开发的代码的程序员所引起。讨论中的 Java 代码允许用户不必去写 Palm OS 本地代码来创建 Palm 个人数码助理应用。通过使用图形界面，用户可以创建表单，使用控件对它们进行填充，然后连接控件事件来创建 Palm 应用程序。测试人员发现，这个 Java 应用最终发生了内存溢出——表单和控件的创建和删除延时。开发人员并没有发现这个问题存在，因为他们的机器(相对 Palm)拥有着更多的物理内存。
为了讨论这个问题，我使用了 JProbe 来断定问题的存在。即使拥有 JProde 提供的强大工具和内存快照，调查仍然是一个繁琐的、反复的过程，它涉及先确定内存泄漏的原因，然后做出代码更改并验证其效果。
JProbe 有几个选项来控制在一次调试回话期间什么样的信息会被记录。经过一些试验后，我判定获取所需信息的最有效的方式是关掉性能数据收集，专注于捕获的堆数据。JProbe 提供了一个叫做运行时堆摘要的视图来显示 Java 应用程序在一段时间内使用的堆内存的数量。它同时也提供了一个工具栏按钮用来在需要时强制 JVM 执行垃圾收集 --在想要看一下一个类的给定实例不再为 Java 应用程序需要时是否会被垃圾收集，这个功能是很有用的。下图显示了在一段时间内使用的堆存储量。
在堆使用情况图中，蓝色部分表示已分配的堆空间量。我启动 Java 程序之后它达到了一个稳定点，我强制垃圾收集器执行，这由绿线之前的蓝色曲线的一个骤降表示(这条绿线表示一个检查点被插入)。接下来，我先是添加而后删掉了四个表单并再次调用垃圾收集器。检查点之后的蓝色曲线的水平线比检查点之前的蓝色曲线的水平线高的事实告诉我们很可能出现了内存泄漏，因为该程序已经回归其只有一个简单可见的表单的初始状态。我检查实例确认了泄漏。总之，结果表明 FormFrame 类(表单的主 UI 类)的数量在检查点之后增加了四个。
寻找原因
要想将测试人员提交的问题隔离出来，第一步就是提供一些简单的、重复的测试用例。以上面那个例子为例，我发现简单地添加一个表单，删除这个表单，然后强制垃圾收集器的结果是一些关联到已经删除掉的表单的实例仍然存活着。这种问题通过 JProbe实例摘要视图来看是显而易见的，视图中统计了堆内存中每个类的实例的个数。
要定位垃圾收集器工作时具体实例的引用，我使用了 JProbe 的引用画面，如下图所示，来断定哪些类仍然在引用已被删除掉的 FormFrame 类。这是调试这种问题的巧妙地方法之一，我通过它发现了很多不同的对象仍然在引用那些无用的对象。而通过试错来查明究竟是哪个引用者真正造成这个问题的过程却是相当耗时的。
在这个案例中，根类(左上角红色的那个)是出现问题的起源。右侧用蓝色突出的那个类就是追踪到的 FormFrame 类。
对于这个具体的例子，找到的罪魁祸首是一个包含一个静态的哈希表的字体管理类。通过引用列表追踪后，我发现根节点是一个静态的哈希表，这个哈希表保存了每个表单使用的字体。各种表单可以被独立地放大或缩小，所以哈希表包含了一个具有每个指定的表单的所有字体的向量。当表单的缩放视图改变时，带有字体的向量被获取并选择合适的缩放因素来适应字体大小。
这个字体管理器的问题是，在创建表单时，当代码将字体向量放进哈希表时，却没有定义表单删除时对向量的移除。因此，这个在整个应用程序的生命周期都存在的静态的哈希表，却从来没有移除指向每个表单的键值。所以，所有的表单和其相关联的类被遗留在了内存中。
问题修正
对于这个问题的简单解决方案就是字体管理器增加一个方法，来允许哈希表的 remove() 方法会在用户删除表单时被调用到。增加的 removeKeyFromHashtables() 方法如下所示：
[java] view plaincopyprint?
31 public void removeKeyFromHashtables(GraphCanvas graph) {
32 if (graph != null) {
33 viewFontTable.remove(graph); // remove key from hashtable
34 // to prevent memory leak
35 }
36 }
然后，我在 FormFrame 类里添加了对这个方法的一个调用。FormFrame 使用 Swing 的内部框架来实现表单 UI，因此对于字体管理器的调用被添加到当内部框架完全关闭时所执行的方法，如下所示：
[java] view plaincopyprint?
37 /**
38 * Invoked when a FormFrame is disposed. Clean out references to prevent
39 * memory leaks.
40 */
41 public void internalFrameClosed(InternalFrameEvent e) {
42 FontManager.get().removeKeyFromHashtables(canvas);
43 canvas = null;
44 setDesktopIcon(null);
45 }
在我对代码做出修改以后，我使用调试工具来确认在相同的测试用例被执行时删除表单所关联到的对象的数目。
内存泄漏的防止
可以通过对一些常见问题的注意来防止内存泄漏。容器类，比如哈希表和向量，是找到引起内存泄漏的常见的地方。尤其是当这些类被声明为静态的并存活于应用程序的整个生命周期之中时。
另一个常见(导致内存泄漏的)问题是当你将一个类注册为事件监听器，却没考虑到当这个类不再需要时将其注销。还有，指向其他类的成员变量在恰当的时候要设置为 null。
结束语
寻找内存泄漏的原因可能是一个繁琐的过程，还没有提到的一点是这将需要特殊的调试工具。然而，一旦你熟悉了追踪对象引用的工具和模式，你将能够跟踪内存泄漏。此外，你还会获得一些有价值的技能，不仅可以节省项目编程投入，而且在以后的项目中你将拥有找出可以防止发生内存泄漏的编程做法的眼光
1、性能测试总结之内存泄露和内存溢出
2、java垃圾回收和内存泄露的讲解
3、Java 内存泄露浅析
1、性能测试总结之内存泄露和内存溢出
http://lya041.blog.51cto.com/337966/668766
刚刚做完了一个项目的性能测试，“有幸”也遇到了内存泄露的案例，所以在此和大家分享一下。
主要从以下几部分来说明，关于内存和内存泄露、溢出的概念，区分内存泄露和内存溢出；内存的区域划分，了解GC回收机制；重点关注如何去监控和发现内存问题；此外分析出问题还要如何解决内存问题。
下面就开始本篇的内容：
第一部分 概念
众所周知，java中的内存java虚拟机自己去管理的，他不想C++需要自己去释放。笼统地去讲，java的内存分配分为两个部分，一个是数据堆，一个是栈。程序在运行的时候一般分配数据堆，把局部的临时的变量都放进去，生命周期和进程有关系。但是如果程序员声明了static的变量，就直接在栈中运行的，进程销毁了，不一定会销毁static变量。
另外为了保证java内存不会溢出，java中有垃圾回收机制。 System.gc()即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。
而其中，内存溢出就是你要求分配的java虚拟机内存超出了系统能给你的，系统不能满足需求，于是产生溢出。
内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问,该块已分配出来的内存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐无内存使用，就会溢出。
第二部分 原理
JAVA垃圾回收及对内存区划分
在Java虚拟机规范中，提及了如下几种类型的内存空间：
◇ 栈内存（Stack）：每个线程私有的。
◇ 堆内存（Heap）：所有线程公用的。
◇ 方法区（Method Area）：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。
◇ 原生方法栈（Native Method Stack）：主要用于JNI中的原生代码，平时很少涉及。
而Java的使用的是堆内存，java堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，“垃圾回收”也是主要是和堆内存（Heap）有关。
垃圾回收的概念就是JAVA虚拟机（JVM）回收那些不再被引用的对象内存的过程。一般我们认为正在被引用的对象状态为“alive”,而没有被应用或者取不到引用属性的对象状态为“dead”。垃圾回收是一个释放处于”dead”状态的对象的内存的过程。而垃圾回收的规则和算法被动态的作用于应用运行当中，自动回收。
JVM的垃圾回收器采用的是一种分代（generational ）回收策略，用较高的频率对年轻的对象(young generation)进行扫描和回收，这种叫做minor collection，而对老对象(old generation)的检查回收频率要低很多，称为major collection。这样就不需要每次GC都将内存中所有对象都检查一遍，这种策略有利于实时观察和回收。
（Sun JVM 1.3 有两种最基本的内存收集方式：一种称为copying或scavenge，将所有仍然生存的对象搬到另外一块内存后，整块内存就可回收。这种方法有效率，但需要有一定的空闲内存，拷贝也有开销。这种方法用于minor collection。另外一种称为mark-compact，将活着的对象标记出来，然后搬迁到一起连成大块的内存，其他内存就可以回收了。这种方法不需要占用额外的空间，但速度相对慢一些。这种方法用于major collection. ）
一些对象被创建出来只是拥有短暂的生命周期，比如 iterators 和本地变量。
另外一些对象被创建是拥有很长的生命周期，比如 高持久化对象等。
垃圾回收器的分代策略是把内存区划分为几个代，然后为每个代分配一到多个内存区块。当其中一个代用完了分配给他的内存后，JVM会在分配的内存区内执行一个局部的GC（也可以叫minor collection）操作，为了回收处于“dead”状态的对象所占用的内存。局部GC通常要不Full GC要快很多。
JVM定义了两个代，年轻代（yong generation）（有时称为“nursery”托儿所）和老年代(old generation)。年轻代包括 “Eden space（伊甸园）”和两个“survivor spaces”。虚拟内存初始化的时候会把所有对象都分配到 Eden space，并且大部分对象也会在该区域被释放。 当进行 minor GC的时候，VM会把剩下的没有释放的对象从Eden space移动到其中一个survivor spaces当中。此外，VM也会把那些长期存活在survivor spaces 里的对象移动到 老生代的“tenured” space中。当 tenured generation 被填满后，就会产生Full GC，Full GC会相对比较慢因为回收的内容包括了所有的 live状态的对象。pemanet generation这个代包括了所有java虚拟机自身使用的相对比较稳定的数据对象，比如类和对象方法等。
关于代的划分，可以从下图中获得一个概况：
如果垃圾回收器影响了系统的性能，或者成为系统的瓶颈，你可以通过自定义各个代的大小来优化它的性能。使用JConsole，可以方便的查看到当前应用所配置的垃圾回收器的各个参数。想要获得更详细的参数，可以参考以下调优介绍：
Tuning Garbage collection with the 5.0 HotSpot VM
http://java.sun.com/docs/hotspot/gc/index.html
最后，总结一下各区内存：
Eden Space (heap)： 内存最初从这个线程池分配给大部分对象。
Survivor Space (heap)：用于保存在eden space内存池中经过垃圾回收后没有被回收的对象。
Tenured Generation (heap)：用于保持已经在 survivor space内存池中存在了一段时间的对象。
Permanent Generation (non-heap): 保存虚拟机自己的静态(refective)数据，例如类（class）和方法（method）对象。Java虚拟机共享这些类数据。这个区域被分割为只读的和只写的，
Code Cache (non-heap):HotSpot Java虚拟机包括一个用于编译和保存本地代码（native code）的内存，叫做“代码缓存区”（code cache）
第三部分 监控（工具发现问题）
谈到内存监控工具，JConsole是必须要介绍的，它是一个用JAVA写的GUI程序，用来监控VM，并可监控远程的VM，易用且功能强大。具体可监控JAVA内存、JAVA CPU使用率、线程执行情况、加载类概况等，Jconsole需要在JVM参数中配置端口才能使用。
由于是GUI程序，界面可视化，这里就不做详细介绍，
具体帮助支持文档请参阅性能测试JConsole使用方法总结：
http://www.taobao.ali.com/chanpin/km/test/DocLib/性能测试辅助工具－JConsole的使用方法.aspx
或者参考SUN官网的技术文档：
http://Java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html
http://Java.sun.com/javase/6/docs/technotes/tools/share/jconsole.html
在实际测试某一个项目时，内存出现泄露现象。起初在性能测试的1个小时中，并不明显，而在稳定性测试的时候才发现，应用的HSF调用在经过几个小时运行后，就出现性能明显下降的情况。在服务日志中报大量HSF超时，但所调用系统没有任何超时日志，并且压力应用的load都很低。经过查看日志后，认为应用可能存在内存泄漏。通过jconsole 以及 jmap 工具进行分析发现，确实存在内存泄漏问题，其中PS Old Gen最终达到占用 100%的占用。
从上图可以看到，虽然每次Full GC，JVM内存会有部分回收，但回收并不彻底，不可回收的内存对象会越来越多，这样便会出现以上的一个趋势。在Full GC无法回收的对象越来越多时，最终已使用内存达到系统分配的内存最大值，系统最后无内存可分配，最终down机。
第四部分 分析
经过开发和架构师对应用的分析，查看此时内存队列，看哪个对象占用数据最多，再利用jmap命令，对线程数据分析，如下所示：
num #instances #bytes class name
———————————————-
1: 9248056 665860032 com.taobao.matrix.mc.domain.**
2: 9248031 295936992 com.taobao.matrix.**
3: 9248068 147969088 java.util.**
4: 1542111 37010664 java.util.Date
前三个instances不断增加，指代的是同一个代码逻辑，异步分发的问题，堵塞消息，回收多次都无法回收成功。导致内存溢出。
此外，对应用的性能单独做了压测，他的性能只能支撑到一半左右，故发送消息的TPS，应用肯定无法处理过来，导致消息堆积，而JAVA垃圾回收期认为这些都是有用的对象，导致内存堆积，直至系统崩溃。
调优方法
由于具体调优方法涉及到应用的配置信息，故在此暂不列出，可以参考性能测试小组发布的《性能测试调优宝典》
第四部分 总结
内存溢出主要是由于代码编写时对某些方法、类应用不合理，或者没有预估到临时对象会占用很大内存量，或者把过多的数据放入JVM缓存，或者性能压力大导致消息堆积而占用内存，以至于在性能测试时，生成庞大数量的临时对象，GC时没有做出有效回收甚至根本就不能回收，造成内存空间不足，内存溢出。
如果编码之前，对内存使用量进行预估，对放在内存中的数据进行评估，保证有用的信息尽快释放，无用的信息能够被GC回收，这样在一定程度上是可以避免内存溢出问题的。
2、java垃圾回收和内存泄露的讲解
http://lya041.blog.51cto.com/337966/665325
1．垃圾收集算法的核心思想
Java语言建立了垃圾收集机制，用以跟踪正在使用的对象和发现并回收不再使用（引用）的对象。该机制可以有效防范动态内存分配中可能发生的两个危险：因内存垃圾过多而引发的内存耗尽，以及不恰当的内存释放所造成的内存非法引用。
垃圾收集算法的核心思想是：对虚拟机可用内存空间，即堆空间中的对象进行识别，如果对象正在被引用，那么称其为存活 对象，反之，如果对象不再被引用，则为垃圾对象，可以回收其占据的空间，用于再分配。垃圾收集算法的选择和垃圾收集系统参数的合理调节直接影响着系统性 能，因此需要开发人员做比较深入的了解。
2．触发主GC（Garbage Collector）的条件
JVM进行次GC的频率很高,但因为这种GC占用时间极短,所以对系统产生的影响不大。更值得关注的是主GC的触发条件,因为它对系统影响很明显。总的来说,有两个条件会触发主GC:
①当应用程序空闲时,即没有应用线程在运行时,GC会被调用。因为GC在优先级最低的线程中进行,所以当应用忙时,GC线程就不会被调用,但以下条件除外。
②Java堆内存不足时,GC会被调用。当应用线程在运行,并在运行过程中创建新对象,若这时内存空间不足,JVM 就会强制地调用GC线程,以便回收内存用于新的分配。若GC一次之后仍不能满足内存分配的要求,JVM会再进行两次GC作进一步的尝试,若仍无法满足要 求,则 JVM将报“out of memory”的错误,Java应用将停止。
由于是否进行主GC由JVM根据系统环境决定,而系统环境在不断的变化当中,所以主GC的运行具有不确定性,无法预计它何时必然出现,但可以确定的是对一个长期运行的应用来说,其主GC是反复进行的。
3．减少GC开销的措施
根据上述GC的机制,程序的运行会直接影响系统环境的变化,从而影响GC的触发。若不针对GC的特点进行设计和编码,就会出现内存驻留等一系列负面影响。为了避免这些影响,基本的原则就是尽可能地减少垃圾和减少GC过程中的开销。具体措施包括以下几个方面:
(1)不要显式调用System.gc()
此函数建议JVM进行主GC,虽然只是建议而非一定,但很多情况下它会触发主GC,从而增加主GC的频率,也即增加了间歇性停顿的次数。
(2)尽量减少临时对象的使用
临时对象在跳出函数调用后,会成为垃圾,少用临时变量就相当于减少了垃圾的产生,从而延长了出现上述第二个触发条件出现的时间,减少了主GC的机会。
(3)对象不用时最好显式置为Null
一般而言,为Null的对象都会被作为垃圾处理,所以将不用的对象显式地设为Null,有利于GC收集器判定垃圾,从而提高了GC的效率。
(4)尽量使用StringBuffer,而不用String来累加字符串（详见blog另一篇文章JAVA中String与StringBuffer）
由于String是固定长的字符串对象,累加String对象时,并非在一个String对象中扩增,而是重新创建 新的String对象,如Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+”操作时都必须创建 新的String对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。避免这种情况可以改用StringBuffer来累加字符串,因 StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象。
(5)能用基本类型如Int,Long,就不用Integer,Long对象
基本类型变量占用的内存资源比相应对象占用的少得多,如果没有必要,最好使用基本变量。
(6)尽量少用静态对象变量
静态变量属于全局变量,不会被GC回收,它们会一直占用内存。
(7)分散对象创建或删除的时间
集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM在面临这种情况时,只能进行主GC, 以回收内存或整合内存碎片,从而增加主GC的频率。集中删除对象,道理也是一样的。它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下 一次创建新对象时强制主GC的机会。
4．gc与finalize方法
⑴gc方法请求垃圾回收
使用System.gc()可以不管JVM使用的是哪一种垃圾回收的算法，都可以请求Java的垃圾回收。需要注意 的是，调用System.gc()也仅仅是一个请求。JVM接受这个消息后，并不是立即做垃圾回收，而只是对几个垃圾回收算法做了加权，使垃圾回收操作容 易发生，或提早发生，或回收较多而已。
⑵finalize方法透视垃圾收集器的运行
在JVM垃圾收集器收集一个对象之前 ，一般要求程序调用适当的方法释放资源，但在没有明确释放资源的情况下，Java提供了缺省机制来终止化该对象释放资源，这个方法就是finalize（）。它的原型为：
protected void finalize() throws Throwable
在finalize()方法返回之后，对象消失，垃圾收集开始执行。原型中的throws Throwable表示它可以抛出任何类型的异常。
因此，当对象即将被销毁时，有时需要做一些善后工作。可以把这些操作写在finalize()方法里。
protected void finalize()
{
// finalization code here
}
⑶代码示例
class Garbage
{
int index;
static int count;
Garbage()
{
count++;
System.out.println("object "+count+" construct");
setID(count);
}
void setID(int id)
{
index=id;
}
protected void finalize() //重写finalize方法
{
System.out.println("object "+index+" is reclaimed");
}
public static void main(String[] args)
{
new Garbage();
new Garbage();
new Garbage();
new Garbage();
System.gc(); //请求运行垃圾收集器
}
}
5．Java 内存泄漏
由于采用了垃圾回收机制，任何不可达对象（对象不再被引用）都可以由垃圾收集线程回收。因此通常说的Java 内存泄漏其实是指无意识的、非故意的对象引用，或者无意识的对象保持。无意识的对象引用是指代码的开发人员本来已经对对象使用完毕，却因为编码的错误而意 外地保存了对该对象的引用（这个引用的存在并不是编码人员的主观意愿），从而使得该对象一直无法被垃圾回收器回收掉，这种本来以为可以释放掉的却最终未能 被释放的空间可以认为是被“泄漏了”。
考虑下面的程序,在ObjStack类中,使用push和pop方法来管理堆栈中的对象。两个方法中的索引 (index)用于指示堆栈中下一个可用位置。push方法存储对新对象的引用并增加索引值,而pop方法减小索引值并返回堆栈最上面的元素。在main 方法中,创建了容量为64的栈,并64次调用push方法向它添加对象,此时index的值为64,随后又32次调用pop方法,则index的值变为 32,出栈意味着在堆栈中的空间应该被收集。但事实上,pop方法只是减小了索引值,堆栈仍然保持着对那些对象的引用。故32个无用对象不会被GC回收, 造成了内存渗漏。
public class ObjStack {
private Object[] stack;
private int index;
ObjStack(int indexcount) {
stack = new Object[indexcount];
index = 0;
}
public void push(Object obj) {
stack[index] = obj;
index++;
}
public Object pop() {
index--;
returnstack[index];
}
}
public class Pushpop {
public static void main(String[] args) {
int i = 0;
Object tempobj;
ObjStack stack1 = new ObjStack(64);//new一个ObjStack对象，并调用有参构造函数。分配stack Obj数组的空间大小为64，可以存64个对象，从0开始存储。
while (i < 64)
{
tempobj = new Object();//循环new Obj对象，把每次循环的对象一一存放在stack Obj数组中。
stack1.push(tempobj);
i++;
System.out.println("第" + i + "次进栈" + "/t");
}
while (i > 32)
{
tempobj = stack1.pop();//这里造成了空间的浪费。
//正确的pop方法可改成如下所指示,当引用被返回后,堆栈删除对他们的引用,因此垃圾收集器在以后可以回收他们。
/* * public Object pop() {index - -;Object temp = stack [index];stack [index]=null;return temp;}
*/ i--;
System.out.println("第" + (64 - i) + "次出栈" + "/t");
}
}
}
如何消除内存泄漏
虽然Java虚拟机(JVM)及其垃圾收集器(garbage collector，GC)负责管理大多数的内存任务，Java软件程序中还是有可能出现内存泄漏。实际上，这在大型项目中是一个常见的问题。避免内存泄 漏的第一步是要弄清楚它是如何发生的。本文介绍了编写Java代码的一些常见的内存泄漏陷阱，以及编写不泄漏代码的一些最佳实践。一旦发生了内存泄漏，要 指出造成泄漏的代码是非常困难的。因此本文还介绍了一种新工具，用来诊断泄漏并指出根本原因。该工具的开销非常小，因此可以使用它来寻找处于生产中的系统 的内存泄漏。
垃圾收集器的作用
虽然垃圾收集器处理了大多数内存管理问题，从而使编程人员的生活变得更轻松了，但是编程人员还是可能犯错而导致 出现内存问题。简单地说，GC循环地跟踪所有来自“根”对象（堆栈对象、静态对象、JNI句柄指向的对象，诸如此类）的引用，并将所有它所能到达的对象标 记为活动的。程序只可以操纵这些对象；其他的对象都被删除了。因为GC使程序不可能到达已被删除的对象，这么做就是安全的。
虽然内存管理可以说是自动化的，但是这并不能使编程人员免受思考内存管理问题之苦。例如，分配（以及释放）内存 总会有开销，虽然这种开销对编程人员来说是不可见的。创建了太多对象的程序将会比完成同样的功能而创建的对象却比较少的程序更慢一些（在其他条件相同的情 况下）。
而且，与本文更为密切相关的是，如果忘记“释放”先前分配的内存，就可能造成内存泄漏。如果程序保留对永远不再 使用的对象的引用，这些对象将会占用并耗尽内存，这是因为自动化的垃圾收集器无法证明这些对象将不再使用。正如我们先前所说的，如果存在一个对对象的引 用，对象就被定义为活动的，因此不能删除。为了确保能回收对象占用的内存，编程人员必须确保该对象不能到达。这通常是通过将对象字段设置为null或者从 集合(collection)中移除对象而完成的。但是，注意，当局部变量不再使用时，没有必要将其显式地设置为null。对这些变量的引用将随着方法的 退出而自动清除。
概括地说，这就是内存托管语言中的内存泄漏产生的主要原因：保留下来却永远不再使用的对象引用。
典型泄漏
既然我们知道了在Java中确实有可能发生内存泄漏，就让我们来看一些典型的内存泄漏及其原因。
全局集合
在大的应用程序中有某种全局的数据储存库是很常见的，例如一个JNDI树或一个会话表。在这些情况下，必须注意管理储存库的大小。必须有某种机制从储存库中移除不再需要的数据。
这可能有多种方法，但是最常见的一种是周期性运行的某种清除任务。该任务将验证储存库中的数据，并移除任何不再需要的数据。
另一种管理储存库的方法是使用反向链接(referrer)计数。然后集合负责统计集合中每个入口的反向链接的数目。这要求反向链接告诉集合何时会退出入口。当反向链接数目为零时，该元素就可以从集合中移除了。
缓存
缓存是一种数据结构，用于快速查找已经执行的操作的结果。因此，如果一个操作执行起来很慢，对于常用的输入数据，就可以将操作的结果缓存，并在下次调用该操作时使用缓存的数据。
缓存通常都是以动态方式实现的，其中新的结果是在执行时添加到缓存中的。典型的算法是：
检查结果是否在缓存中，如果在，就返回结果。
如果结果不在缓存中，就进行计算。
将计算出来的结果添加到缓存中，以便以后对该操作的调用可以使用。
该算法的问题（或者说是潜在的内存泄漏）出在最后一步。如果调用该操作时有相当多的不同输入，就将有相当多的结果存储在缓存中。很明显这不是正确的方法。
为了预防这种具有潜在破坏性的设计，程序必须确保对于缓存所使用的内存容量有一个上限。因此，更好的算法是：
检查结果是否在缓存中，如果在，就返回结果。
如果结果不在缓存中，就进行计算。
如果缓存所占的空间过大，就移除缓存最久的结果。
将计算出来的结果添加到缓存中，以便以后对该操作的调用可以使用。
通过始终移除缓存最久的结果，我们实际上进行了这样的假设：在将来，比起缓存最久的数据，最近输入的数据更有可能用到。这通常是一个不错的假设。
新算法将确保缓存的容量处于预定义的内存范围之内。确切的范围可能很难计算，因为缓存中的对象在不断变化，而且它们的引用包罗万象。为缓存设置正确的大小是一项非常复杂的任务，需要将所使用的内存容量与检索数据的速度加以平衡。
解决这个问题的另一种方法是使用java.lang.ref.SoftReference类跟踪缓存中的对象。这种方法保证这些引用能够被移除，如果虚拟机的内存用尽而需要更多堆的话。
ClassLoader
Java ClassLoader结构的使用为内存泄漏提供了许多可乘之机。正是该结构本身的复杂性使ClassLoader在内存泄漏方面存在如此多的问题。 ClassLoader的特别之处在于它不仅涉及“常规”的对象引用，还涉及元对象引用，比如：字段、方法和类。这意味着只要有对字段、方法、类或 ClassLoader的对象的引用，ClassLoader就会驻留在JVM中。因为ClassLoader本身可以关联许多类及其静态字段，所以就有 许多内存被泄漏了。
确定泄漏的位置
通常发生内存泄漏的第一个迹象是：在应用程序中出现了OutOfMemoryError。这通常发生在您最不愿 意它发生的生产环境中，此时几乎不能进行调试。有可能是因为测试环境运行应用程序的方式与生产系统不完全相同，因而导致泄漏只出现在生产中。在这种情况 下，需要使用一些开销较低的工具来监控和查找内存泄漏。还需要能够无需重启系统或修改代码就可以将这些工具连接到正在运行的系统上。可能最重要的是，当进 行分析时，需要能够断开工具而保持系统不受干扰。
虽然OutOfMemoryError通常都是内存泄漏的信号，但是也有可能应用程序确实正在使用这么多的内 存；对于后者，或者必须增加JVM可用的堆的数量，或者对应用程序进行某种更改，使它使用较少的内存。但是，在许多情况 下，OutOfMemoryError都是内存泄漏的信号。一种查明方法是不间断地监控GC的活动，确定内存使用量是否随着时间增加。如果确实如此，就可 能发生了内存泄漏。
3、Java 内存泄露浅析
Java使用有向图的方式进行内存管理，
优点：可以消除引用循环的问题，管理内存精度高
缺点：效率低下（相比引用计数）。
什么是Java中内存泄漏：
在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点：
<一>：这些对象是可达的
<二>：这些对象是无用的
这些对象不会被GC所回收，然而它却占用内存。
Java内存泄漏的方面：
静态集合变量：HashMap, Hashtable,等，由于这些集合不断调用add()方法增加一些临时对象，而没有及时调用remove()方法移除临时对象的引用,
导致一些无用的临时对象不能被JVM回收，造成内存泄漏
单例对象：如果该对象持有另外一个对象A的引用，那么对象A不会被回收，当对象A是一个比较大的对象时，会造成严重的内存泄漏。
Web容器中的request, session, application对象：对于request,session，如果并发量较大，而每个request, session都持有较多临时对象的引用，
会导致服务器内存溢出。对于application对象和Web容器中一些具有很长生命周期的对象，长期持有一些临时对象，也会造成内存泄漏。
JDBC操作出现异常，没有及时关闭连接(Connection)对象，会导致内存泄漏。
文件流操作出现异常，没有及时关闭文件流(InputStream)对象，导致内存泄漏。
Http请求超时设置：如果超时设置的时间是无限长，那么当一个Http请求的线程被卡住时，这个线程所占有的资源会永远不会释放，导致内存泄漏。
46 博客园
47 首页
48 博问
49 闪存
50 新随笔
51 联系
52 订阅
53 管理
随笔-20 文章-1 评论-0
1.JMM简介
i.内存模型概述
Java平台自动集成了线程以及多处理器技术，这种集成程度比Java以前诞生的计算机语言要厉害很多，该语言针对多种异构平台的平台独立性而使用的多线程技术支持也是具有开拓性的一面，有时候在开发Java同步和线程安全要求很严格的程序时，往往容易混淆的一个概念就是内存模型。究竟什么是内存模型？内存模型描述了程序中各个变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存中取出变量这样的底层细节，对象最终是存储在内存里面的，这点没有错，但是编译器、运行库、处理器或者系统缓存可以有特权在变量指定内存位置存储或者取出变量的值。【JMM】（Java Memory Model的缩写）允许编译器和缓存以数据在处理器特定的缓存（或寄存器）和主存之间移动的次序拥有重要的特权，除非程序员使用了final或synchronized明确请求了某些可见性的保证。
1)JSR133：
在Java语言规范里面指出了JMM是一个比较开拓性的尝试，这种尝试视图定义一个一致的、跨平台的内存模型，但是它有一些比较细微而且很重要的缺点。其实Java语言里面比较容易混淆的关键字主要是synchronized和volatile，也因为这样在开发过程中往往开发者会忽略掉这些规则，这也使得编写同步代码比较困难。
JSR133本身的目的是为了修复原本JMM的一些缺陷而提出的，其本身的制定目标有以下几个：
54 保留目前JVM的安全保证，以进行类型的安全检查：
55 提供（out-of-thin-air safety）无中生有安全性，这样“正确同步的”应该被正式而且直观地定义
56 程序员要有信心开发多线程程序，当然没有其他办法使得并发程序变得很容易开发，但是该规范的发布主要目标是为了减轻程序员理解内存模型中的一些细节负担
57 提供大范围的流行硬件体系结构上的高性能JVM实现，现在的处理器在它们的内存模型上有着很大的不同，JMM应该能够适合于实际的尽可能多的体系结构而不以性能为代价，这也是Java跨平台型设计的基础
58 提供一个同步的习惯用法，以允许发布一个对象使他不用同步就可见，这种情况又称为初始化安全（initialization safety）的新的安全保证
59 对现有代码应该只有最小限度的影响
2)同步、异步【这里仅仅指概念上的理解，不牵涉到计算机底层基础的一些操作】：
在系统开发过程，经常会遇到这几个基本概念，不论是网络通讯、对象之间的消息通讯还是Web开发人员常用的Http请求都会遇到这样几个概念，经常有人提到Ajax是异步通讯方式，那么究竟怎样的方式是这样的概念描述呢？
同步：同步就是在发出一个功能调用的时候，在没有得到响应之前，该调用就不返回，按照这样的定义，其实大部分程序的执行都是同步调用的，一般情况下，在描述同步和异步操作的时候，主要是指代需要其他部件协作处理或者需要协作响应的一些任务处理。比如有一个线程A，在A执行的过程中，可能需要B提供一些相关的执行数据，当然触发B响应的就是A向B发送一个请求或者说对B进行一个调用操作，如果A在执行该操作的时候是同步的方式，那么A就会停留在这个位置等待B给一个响应消息，在B没有任何响应消息回来的时候，A不能做其他事情，只能等待，那么这样的情况，A的操作就是一个同步的简单说明。
异步：异步就是在发出一个功能调用的时候，不需要等待响应，继续进行它该做的事情，一旦得到响应了过后给予一定的处理，但是不影响正常的处理过程的一种方式。比如有一个线程A，在A执行的过程中，同样需要B提供一些相关数据或者操作，当A向B发送一个请求或者对B进行调用操作过后，A不需要继续等待，而是执行A自己应该做的事情，一旦B有了响应过后会通知A，A接受到该异步请求的响应的时候会进行相关的处理，这种情况下A的操作就是一个简单的异步操作。
3)可见性、可排序性
Java内存模型的两个关键概念：可见性（Visibility）和可排序性（Ordering）
开发过多线程程序的程序员都明白，synchronized关键字强制实施一个线程之间的互斥锁（相互排斥），该互斥锁防止每次有多个线程进入一个给定监控器所保护的同步语句块，也就是说在该情况下，执行程序代码所独有的某些内存是独占模式，其他的线程是不能针对它执行过程所独占的内存进行访问的，这种情况称为该内存不可见。但是在该模型的同步模式中，还有另外一个方面：JMM中指出了，JVM在处理该强制实施的时候可以提供一些内存的可见规则，在该规则里面，它确保当存在一个同步块时，缓存被更新，当输入一个同步块时，缓存失效。因此在JVM内部提供给定监控器保护的同步块之中，一个线程所写入的值对于其余所有的执行由同一个监控器保护的同步块线程来说是可见的，这就是一个简单的可见性的描述。这种机器保证编译器不会把指令从一个同步块的内部移到外部，虽然有时候它会把指令由外部移动到内部。JMM在缺省情况下不做这样的保证——只要有多个线程访问相同变量时必须使用同步。简单总结：
可见性就是在多核或者多线程运行过程中内存的一种共享模式，在JMM模型里面，通过并发线程修改变量值的时候，必须将线程变量同步回主存过后，其他线程才可能访问到。
【*：简单讲，内存的可见性使内存资源可以共享，当一个线程执行的时候它所占有的内存，如果它占有的内存资源是可见的，那么这时候其他线程在一定规则内是可以访问该内存资源的，这种规则是由JMM内部定义的，这种情况下内存的该特性称为其可见性。】
可排序性提供了内存内部的访问顺序，在不同的程序针对不同的内存块进行访问的时候，其访问不是无序的，比如有一个内存块，A和B需要访问的时候，JMM会提供一定的内存分配策略有序地分配它们使用的内存，而在内存的调用过程也会变得有序地进行，内存的折中性质可以简单理解为有序性。而在Java多线程程序里面，JMM通过Java关键字volatile来保证内存的有序访问。
ii.JMM结构：
1)简单分析：
Java语言规范中提到过，JVM中存在一个主存区（Main Memory或Java Heap Memory），Java中所有变量都是存在主存中的，对于所有线程进行共享，而每个线程又存在自己的工作内存（Working Memory），工作内存中保存的是主存中某些变量的拷贝，线程对所有变量的操作并非发生在主存区，而是发生在工作内存中，而线程之间是不能直接相互访问，变量在程序中的传递，是依赖主存来完成的。而在多核处理器下，大部分数据存储在高速缓存中，如果高速缓存不经过内存的时候，也是不可见的一种表现。在Java程序中，内存本身是比较昂贵的资源，其实不仅仅针对Java应用程序，对操作系统本身而言内存也属于昂贵资源，Java程序在性能开销过程中有几个比较典型的可控制的来源。synchronized和volatile关键字提供的内存中模型的可见性保证程序使用一个特殊的、存储关卡（memory barrier）的指令，来刷新缓存，使缓存无效，刷新硬件的写缓存并且延迟执行的传递过程，无疑该机制会对Java程序的性能产生一定的影响。
JMM的最初目的，就是为了能够支持多线程程序设计的，每个线程可以认为是和其他线程不同的CPU上运行，或者对于多处理器的机器而言，该模型需要实现的就是使得每一个线程就像运行在不同的机器、不同的CPU或者本身就不同的线程上一样，这种情况实际上在项目开发中是常见的。对于CPU本身而言，不能直接访问其他CPU的寄存器，模型必须通过某种定义规则来使得线程和线程在工作内存中进行相互调用而实现CPU本身对其他CPU、或者说线程对其他线程的内存中资源的访问，而表现这种规则的运行环境一般为运行该程序的运行宿主环境（操作系统、服务器、分布式系统等），而程序本身表现就依赖于编写该程序的语言特性，这里也就是说用Java编写的应用程序在内存管理中的实现就是遵循其部分原则，也就是前边提及到的JMM定义了Java语言针对内存的一些的相关规则。然而，虽然设计之初是为了能够更好支持多线程，但是该模型的应用和实现当然不局限于多处理器，而在JVM编译器编译Java编写的程序的时候以及运行期执行该程序的时候，对于单CPU的系统而言，这种规则也是有效的，这就是是上边提到的线程和线程之间的内存策略。JMM本身在描述过程没有提过具体的内存地址以及在实现该策略中的实现方法是由JVM的哪一个环节（编译器、处理器、缓存控制器、其他）提供的机制来实现的，甚至针对一个开发非常熟悉的程序员，也不一定能够了解它内部对于类、对象、方法以及相关内容的一些具体可见的物理结构。相反，JMM定义了一个线程与主存之间的抽象关系，其实从上边的图可以知道，每一个线程可以抽象成为一个工作内存（抽象的高速缓存和寄存器），其中存储了Java的一些值，该模型保证了Java里面的属性、方法、字段存在一定的数学特性，按照该特性，该模型存储了对应的一些内容，并且针对这些内容进行了一定的序列化以及存储排序操作，这样使得Java对象在工作内存里面被JVM顺利调用，（当然这是比较抽象的一种解释）既然如此，大多数JMM的规则在实现的时候，必须使得主存和工作内存之间的通信能够得以保证，而且不能违反内存模型本身的结构，这是语言在设计之处必须考虑到的针对内存的一种设计方法。这里需要知道的一点是，这一切的操作在Java语言里面都是依靠Java语言自身来操作的，因为Java针对开发人员而言，内存的管理在不需要手动操作的情况下本身存在内存的管理策略，这也是Java自己进行内存管理的一种优势。
[1]原子性（Atomicity）：
这一点说明了该模型定义的规则针对原子级别的内容存在独立的影响，对于模型设计最初，这些规则需要说明的仅仅是最简单的读取和存储单元写入的的一些操作，这种原子级别的包括——实例、静态变量、数组元素，只是在该规则中不包括方法中的局部变量。
[2]可见性（Visibility）：
在该规则的约束下，定义了一个线程在哪种情况下可以访问另外一个线程或者影响另外一个线程，从JVM的操作上讲包括了从另外一个线程的可见区域读取相关数据以及将数据写入到另外一个线程内。
[3]可排序性（Ordering）：
该规则将会约束任何一个违背了规则调用的线程在操作过程中的一些顺序，排序问题主要围绕了读取、写入和赋值语句有关的序列。
如果在该模型内部使用了一致的同步性的时候，这些属性中的每一个属性都遵循比较简单的原则：和所有同步的内存块一样，每个同步块之内的任何变化都具备了原子性以及可见性，和其他同步方法以及同步块遵循同样一致的原则，而且在这样的一个模型内，每个同步块不能使用同一个锁，在整个程序的调用过程是按照编写的程序指定指令运行的。即使某一个同步块内的处理可能会失效，但是该问题不会影响到其他线程的同步问题，也不会引起连环失效。简单讲：当程序运行的时候使用了一致的同步性的时候，每个同步块有一个独立的空间以及独立的同步控制器和锁机制，然后对外按照JVM的执行指令进行数据的读写操作。这种情况使得使用内存的过程变得非常严谨！
如果不使用同步或者说使用同步不一致（这里可以理解为异步，但不一定是异步操作），该程序执行的答案就会变得极其复杂。而且在这样的情况下，该内存模型处理的结果比起大多数程序员所期望的结果而言就变得十分脆弱，甚至比起JVM提供的实现都脆弱很多。因为这样所以出现了Java针对该内存操作的最简单的语言规范来进行一定的习惯限制，排除该情况发生的做法在于：
JVM线程必须依靠自身来维持对象的可见性以及对象自身应该提供相对应的操作而实现整个内存操作的三个特性，而不是仅仅依靠特定的修改对象状态的线程来完成如此复杂的一个流程。
【*：综上所属，JMM在JVM内部实现的结构就变得相对复杂，当然一般的Java初学者可以不用了解得这么深入。】
[4]三个特性的解析（针对JMM内部）：
原子性（Atomicity）：
访问存储单元内的任何类型的字段的值以及对其更新操作的时候，除开long类型和double类型，其他类型的字段是必须要保证其原子性的，这些字段也包括为对象服务的引用。此外，该原子性规则扩展可以延伸到基于long和double的另外两种类型：volatile long和volatile double（volatile为java关键字），没有被volatile声明的long类型以及double类型的字段值虽然不保证其JMM中的原子性，但是是被允许的。针对non-long/non-double的字段在表达式中使用的时候，JMM的原子性有这样一种规则：如果你获得或者初始化该值或某一些值的时候，这些值是由其他线程写入，而且不是从两个或者多个线程产生的数据在同一时间戳混合写入的时候，该字段的原子性在JVM内部是必须得到保证的。也就是说JMM在定义JVM原子性的时候，只要在该规则不违反的条件下，JVM本身不去理睬该数据的值是来自于什么线程，因为这样使得Java语言在并行运算的设计的过程中针对多线程的原子性设计变得极其简单，而且即使开发人员没有考虑到最终的程序也没有太大的影响。再次解释一下：这里的原子性指的是原子级别的操作，比如最小的一块内存的读写操作，可以理解为Java语言最终编译过后最接近内存的最底层的操作单元，这种读写操作的数据单元不是变量的值，而是本机码，也就是前边在讲《Java基础知识》中提到的由运行器解释的时候生成的Native Code。
可见性（Visibility）：
当一个线程需要修改另外线程的可见单元的时候必须遵循以下原则：
60 一个写入线程释放的同步锁和紧随其后进行读取的读线程的同步锁是同一个
从本质上讲，释放锁操作强迫它的隶属线程【释放锁的线程】从工作内存中的写入缓存里面刷新（专业上讲这里不应该是刷新，可以理解为提供）数据（flush操作），然后获取锁操作使得另外一个线程【获得锁的线程】直接读取前一个线程可访问域（也就是可见区域）的字段的值。因为该锁内部提供了一个同步方法或者同步块，该同步内容具有线程排他性，这样就使得上边两个操作只能针对单一线程在同步内容内部进行操作，这样就使得所有操作该内容的单一线程具有该同步内容（加锁的同步方法或者同步块）内的线程排他性，这种情况的交替也可以理解为具有“短暂记忆效应”。
这里需要理解的是同步的双重含义：使用锁机制允许基于高层同步协议进行处理操作，这是最基本的同步；同时系统内存（很多时候这里是指基于机器指令的底层存储关卡memory barrier，前边提到过）在处理同步的时候能够跨线程操作，使得线程和线程之间的数据是同步的。这样的机制也折射出一点，并行编程相对于顺序编程而言，更加类似于分布式编程。后一种同步可以作为JMM机制中的方法在一个线程中运行的效果展示，注意这里不是多个线程运行的效果展示，因为它反应了该线程愿意发送或者接受的双重操作，并且使得它自己的可见区域可以提供给其他线程运行或者更新，从这个角度来看，使用锁和消息传递可以视为相互之间的变量同步，因为相对其他线程而言，它的操作针对其他线程也是对等的。
61 一旦某个字段被申明为volatile，在任何一个写入线程在工作内存中刷新缓存的之前需要进行进一步的内存操作，也就是说针对这样的字段进行立即刷新，可以理解为这种volatile不会出现一般变量的缓存操作，而读取线程每次必须根据前一个线程的可见域里面重新读取该变量的值，而不是直接读取。
62 当某个线程第一次去访问某个对象的域的时候，它要么初始化该对象的值，要么从其他写入线程可见域里面去读取该对象的值；这里结合上边理解，在满足某种条件下，该线程对某对象域的值的读取是直接读取，有些时候却需要重新读取。
这里需要小心一点的是，在并发编程里面，不好的一个实践就是使用一个合法引用去引用不完全构造的对象，这种情况在从其他写入线程可见域里面进行数据读取的时候发生频率比较高。从编程角度上讲，在构造函数里面开启一个新的线程是有一定的风险的，特别是该类是属于一个可子类化的类的时候。Thread.start由调用线程启动，然后由获得该启动的线程释放锁具有相同的“短暂记忆效应”，如果一个实现了Runnable接口的超类在子类构造子执行之前调用了Thread(this).start()方法，那么就可能使得该对象在线程方法run执行之前并没有被完全初始化，这样就使得一个指向该对象的合法引用去引用了不完全构造的一个对象。同样的，如果创建一个新的线程T并且启动该线程，然后再使用线程T来创建对象X，这种情况就不能保证X对象里面所有的属性针对线程T都是可见的除非是在所有针对X对象的引用中进行同步处理，或者最好的方法是在T线程启动之前创建对象X。
63 若一个线程终止，所有的变量值都必须从工作内存中刷到主存，比如，如果一个同步线程因为另一个使用Thread.join方法的线程而终止，那么该线程的可见域针对那个线程而言其发生的改变以及产生的一些影响是需要保证可知道的。
注意：如果在同一个线程里面通过方法调用去传一个对象的引用是绝对不会出现上边提及到的可见性问题的。JMM保证所有上边的规定以及关于内存可见性特性的描述——一个特殊的更新、一个特定字段的修改都是某个线程针对其他线程的一个“可见性”的概念，最终它发生的场所在内存模型中Java线程和线程之间，至于这个发生时间可以是一个任意长的时间，但是最终会发生，也就是说，Java内存模型中的可见性的特性主要是针对线程和线程之间使用内存的一种规则和约定，该约定由JMM定义。
不仅仅如此，该模型还允许不同步的情况下可见性特性。比如针对一个线程提供一个对象或者字段访问域的原始值进行操作，而针对另外一个线程提供一个对象或者字段刷新过后的值进行操作。同样也有可能针对一个线程读取一个原始的值以及引用对象的对象内容，针对另外一个线程读取一个刷新过后的值或者刷新过后的引用。
尽管如此，上边的可见性特性分析的一些特征在跨线程操作的时候是有可能失败的，而且不能够避免这些故障发生。这是一个不争的事实，使用同步多线程的代码并不能绝对保证线程安全的行为，只是允许某种规则对其操作进行一定的限制，但是在最新的JVM实现以及最新的Java平台中，即使是多个处理器，通过一些工具进行可见性的测试发现其实是很少发生故障的。跨线程共享CPU的共享缓存的使用，其缺陷就在于影响了编译器的优化操作，这也体现了强有力的缓存一致性使得硬件的价值有所提升，因为它们之间的关系在线程与线程之间的复杂度变得更高。这种方式使得可见度的自由测试显得更加不切实际，因为这些错误的发生极为罕见，或者说在平台上我们开发过程中根本碰不到。在并行程开发中，不使用同步导致失败的原因也不仅仅是对可见度的不良把握导致的，导致其程序失败的原因是多方面的，包括缓存一致性、内存一致性问题等。
可排序性（Ordering）：
可排序规则在线程与线程之间主要有下边两点：
64 从操作线程的角度看来，如果所有的指令执行都是按照普通顺序进行，那么对于一个顺序运行的程序而言，可排序性也是顺序的
65 从其他操作线程的角度看来，排序性如同在这个线程中运行在非同步方法中的一个“间谍”，所以任何事情都有可能发生。唯一有用的限制是同步方法和同步块的相对排序，就像操作volatile字段一样，总是保留下来使用
【*：如何理解这里“间谍”的意思，可以这样理解，排序规则在本线程里面遵循了第一条法则，但是对其他线程而言，某个线程自身的排序特性可能使得它不定地访问执行线程的可见域，而使得该线程对本身在执行的线程产生一定的影响。举个例子，A线程需要做三件事情分别是A1、A2、A3，而B是另外一个线程具有操作B1、B2，如果把参考定位到B线程，那么对A线程而言，B的操作B1、B2有可能随时会访问到A的可见区域，比如A有一个可见区域a，A1就是把a修改称为1，但是B线程在A线程调用了A1过后，却访问了a并且使用B1或者B2操作使得a发生了改变，变成了2，那么当A按照排序性进行A2操作读取到a的值的时候，读取到的是2而不是1，这样就使得程序最初设计的时候A线程的初衷发生了改变，就是排序被打乱了，那么B线程对A线程而言，其身份就是“间谍”，而且需要注意到一点，B线程的这些操作不会和A之间存在等待关系，那么B线程的这些操作就是异步操作，所以针对执行线程A而言，B的身份就是“非同步方法中的‘间谍’。】
同样的，这仅仅是一个最低限度的保障性质，在任何给定的程序或者平台，开发中有可能发现更加严格的排序，但是开发人员在设计程序的时候不能依赖这种排序，如果依赖它们会发现测试难度会成指数级递增，而且在复合规定的时候会因为不同的特性使得JVM的实现因为不符合设计初衷而失败。
注意：第一点在JLS（Java Language Specification）的所有讨论中也是被采用的，例如算数表达式一般情况都是从上到下、从左到右的顺序，但是这一点需要理解的是，从其他操作线程的角度看来这一点又具有不确定性，对线程内部而言，其内存模型本身是存在排序性的。【*：这里讨论的排序是最底层的内存里面执行的时候的NativeCode的排序，不是说按照顺序执行的Java代码具有的有序性质，本文主要分析的是JVM的内存模型，所以希望读者明白这里指代的讨论单元是内存区。】
iii.原始JMM缺陷：
JMM最初设计的时候存在一定的缺陷，这种缺陷虽然现有的JVM平台已经修复，但是这里不得不提及，也是为了读者更加了解JMM的设计思路，这一个小节的概念可能会牵涉到很多更加深入的知识，如果读者不能读懂没有关系先看了文章后边的章节再返回来看也可以。
1)问题1：不可变对象不是不可变的
学过Java的朋友都应该知道Java中的不可变对象，这一点在本文最后讲解String类的时候也会提及，而JMM最初设计的时候，这个问题一直都存在，就是：不可变对象似乎可以改变它们的值（这种对象的不可变指通过使用final关键字来得到保证），（Publis Service Reminder：让一个对象的所有字段都为final并不一定使得这个对象不可变——所有类型还必须是原始类型而不能是对象的引用。而不可变对象被认为不要求同步的。但是，因为在将内存写方面的更改从一个线程传播到另外一个线程的时候存在潜在的延迟，这样就使得有可能存在一种竞态条件，即允许一个线程首先看到不可变对象的一个值，一段时间之后看到的是一个不同的值。这种情况以前怎么发生的呢？在JDK 1.4中的String实现里，这儿基本有三个重要的决定性字段：对字符数组的引用、长度和描述字符串的开始数组的偏移量。String就是以这样的方式在JDK 1.4中实现的，而不是只有字符数组，因此字符数组可以在多个String和StringBuffer对象之间共享，而不需要在每次创建一个String的时候都拷贝到一个新的字符数组里。假设有下边的代码：
String s1 = "/usr/tmp";
String s2 = s1.substring(4); // "/tmp"
这种情况下，字符串s2将具有大小为4的长度和偏移量，但是它将和s1共享“/usr/tmp”里面的同一字符数组，在String构造函数运行之前，Object的构造函数将用它们默认的值初始化所有的字段，包括决定性的长度和偏移字段。当String构造函数运行的时候，字符串长度和偏移量被设置成所需要的值。但是在旧的内存模型中，因为缺乏同步，有可能另一个线程会临时地看到偏移量字段具有初始默认值0，而后又看到正确的值4，结果是s2的值从“/usr”变成了“/tmp”，这并不是我们真正的初衷，这个问题就是原始JMM的第一个缺陷所在，因为在原始JMM模型里面这是合理而且合法的，JDK 1.4以下的版本都允许这样做。
2)问题2：重新排序的易失性和非易失性存储
另一个主要领域是与volatile字段的内存操作重新排序有关，这个领域中现有的JMM引起了一些比较混乱的结果。现有的JMM表明易失性的读和写是直接和主存打交道的，这样避免了把值存储到寄存器或者绕过处理器特定的缓存，这使得多个线程一般能看见一个给定变量最新的值。可是，结果是这种volatile定义并没有最初想象中那样如愿以偿，并且导致了volatile的重大混乱。为了在缺乏同步的情况下提供较好的性能，编译器、运行时和缓存通常是允许进行内存的重新排序操作的，只要当前执行的线程分辨不出它们的区别。（这就是within-thread as-if-serial semantics[线程内似乎是串行]的解释）但是，易失性的读和写是完全跨线程安排的，编译器或缓存不能在彼此之间重新排序易失性的读和写。遗憾的是，通过参考普通变量的读写，JMM允许易失性的读和写被重排序，这样以为着开发人员不能使用易失性标志作为操作已经完成的标志。比如：
Map configOptions;
char[] configText;
volatile boolean initialized = false;
// 线程1
configOptions = new HashMap();
configText = readConfigFile(filename);
processConfigOptions(configText,configOptions);
initialized = true;
// 线程2
while(!initialized)
sleep();
这里的思想是使用易失性变量initialized担任守卫来表明一套别的操作已经完成了，这是一个很好的思想，但是不能在JMM下工作，因为旧的JMM允许非易失性的写（比如写到configOptions字段，以及写到由configOptions引用Map的字段中）与易失性的写一起重新排序，因此另外一个线程可能会看到initialized为true，但是对于configOptions字段或它所引用的对象还没有一个一致的或者说当前的针对内存的视图变量，volatile的旧语义只承诺在读和写的变量的可见性，而不承诺其他变量，虽然这种方法更加有效的实现，但是结果会和我们设计之初大相径庭。
2.堆和栈
i.Java内存管理简介：
内存管理在Java语言中是JVM自动操作的，当JVM发现某些对象不再需要的时候，就会对该对象占用的内存进行重分配（释放）操作，而且使得分配出来的内存能够提供给所需要的对象。在一些编程语言里面，内存管理是一个程序的职责，但是书写过C++的程序员很清楚，如果该程序需要自己来书写很有可能引起很严重的错误或者说不可预料的程序行为，最终大部分开发时间都花在了调试这种程序以及修复相关错误上。一般情况下在Java程序开发过程把手动内存管理称为显示内存管理，而显示内存管理经常发生的一个情况就是引用悬挂——也就是说有可能在重新分配过程释放掉了一个被某个对象引用正在使用的内存空间，释放掉该空间过后，该引用就处于悬挂状态。如果这个被悬挂引用指向的对象试图进行原来对象（因为这个时候该对象有可能已经不存在了）进行操作的时候，由于该对象本身的内存空间已经被手动释放掉了，这个结果是不可预知的。显示内存管理另外一个常见的情况是内存泄漏，当某些引用不再引用该内存对象的时候，而该对象原本占用的内存并没有被释放，这种情况简言为内存泄漏。比如，如果针对某个链表进行了内存分配，而因为手动分配不当，仅仅让引用指向了某个元素所处的内存空间，这样就使得其他链表中的元素不能再被引用而且使得这些元素所处的内存让应用程序处于不可达状态而且这些对象所占有的内存也不能够被再使用，这个时候就发生了内存泄漏。而这种情况一旦在程序中发生，就会一直消耗系统的可用内存直到可用内存耗尽，而针对计算机而言内存泄漏的严重程度大了会使得本来正常运行的程序直接因为内存不足而中断，并不是Java程序里面出现Exception那么轻量级。
在以前的编程过程中，手动内存管理带了计算机程序不可避免的错误，而且这种错误对计算机程序是毁灭性的，所以内存管理就成为了一个很重要的话题，但是针对大多数纯面向对象语言而言，比如Java，提供了语言本身具有的内存特性：自动化内存管理，这种语言提供了一个程序垃圾回收器（Garbage Collector[GC]），自动内存管理提供了一个抽象的接口以及更加可靠的代码使得内存能够在程序里面进行合理的分配。最常见的情况就是垃圾回收器避免了悬挂引用的问题，因为一旦这些对象没有被任何引用“可达”的时候，也就是这些对象在JVM的内存池里面成为了不可引用对象，该垃圾回收器会直接回收掉这些对象占用的内存，当然这些对象必须满足垃圾回收器回收的某些对象规则，而垃圾回收器在回收的时候会自动释放掉这些内存。不仅仅如此，垃圾回收器同样会解决内存泄漏问题。
ii.详解堆和栈[图片以及部分内容来自《Inside JVM》]：
1)通用简介
[编译原理]学过编译原理的人都明白，程序运行时有三种内存分配策略：静态的、栈式的、堆式的
静态存储——是指在编译时就能够确定每个数据目标在运行时的存储空间需求，因而在编译时就可以给它们分配固定的内存空间。这种分配策略要求程序代码中不允许有可变数据结构的存在，也不允许有嵌套或者递归的结构出现，因为它们都会导致编译程序无法计算准确的存储空间。
栈式存储——该分配可成为动态存储分配，是由一个类似于堆栈的运行栈来实现的，和静态存储的分配方式相反，在栈式存储方案中，程序对数据区的需求在编译时是完全未知的，只有到了运行的时候才能知道，但是规定在运行中进入一个程序模块的时候，必须知道该程序模块所需要的数据区的大小才能分配其内存。和我们在数据结构中所熟知的栈一样，栈式存储分配按照先进后出的原则进行分配。
堆式存储——堆式存储分配则专门负责在编译时或运行时模块入口处都无法确定存储要求的数据结构的内存分配，比如可变长度串和对象实例，堆由大片的可利用块或空闲块组成，堆中的内存可以按照任意顺序分配和释放。
[C++语言]对比C++语言里面，程序占用的内存分为下边几个部分：
[1]栈区（Stack）：由编译器自动分配释放，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。我们在程序中定义的局部变量就是存放在栈里，当局部变量的生命周期结束的时候，它所占的内存会被自动释放。
[2]堆区（Heap）：一般由程序员分配和释放，若程序员不释放，程序结束时可能由OS回收。注意它与数据结构中的堆是两回事，分配方式倒是类似于链表。我们在程序中使用c++中new或者c中的malloc申请的一块内存，就是在heap上申请的，在使用完毕后，是需要我们自己动手释放的，否则就会产生“内存泄露”的问题。
[3]全局区（静态区）（Static）：全局变量和静态变量的存储是放在一块的，初始化的全局变量和静态变量在一块区域，未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。程序结束后由系统释放。
[4]文字常量区：常量字符串就是放在这里的，程序结束后由系统释放。在Java中对应有一个字符串常量池。
[5]程序代码区：存放函数体的二进制代码
2)JVM结构【堆、栈解析】：
在Java虚拟机规范中，一个虚拟机实例的行为主要描述为：子系统、内存区域、数据类型和指令，这些组件在描述了抽象的JVM内部的一个抽象结构。与其说这些组成部分的目的是进行JVM内部结构的一种支配，更多的是提供一种严格定义实现的外部行为，该规范定义了这些抽象组成部分以及相互作用的任何Java虚拟机执行所需要的行为。下图描述了JVM内部的一个结构，其中主要包括主要的子系统、内存区域，如同以前在《Java基础知识》中描述的：Java虚拟机有一个类加载器作为JVM的子系统，类加载器针对Class进行检测以鉴定完全合格的类接口，而JVM内部也有一个执行引擎：
当JVM运行一个程序的时候，它的内存需要用来存储很多内容，包括字节码、以及从类文件中提取出来的一些附加信息、以及程序中实例化的对象、方法参数、返回值、局部变量以及计算的中间结果。JVM的内存组织需要在不同的运行时数据区进行以上的几个操作，下边针对上图里面出现的几个运行时数据区进行详细解析：一些运行时数据区共享了所有应用程序线程和其他特有的单个线程，每个JVM实例有一个方法区和一个内存堆，这些是共同在虚拟机内运行的线程。在Java程序里面，每个新的线程启动过后，它就会被JVM在内部分配自己的PC寄存器[PC registers]（程序计数器器）和Java堆栈（Java stacks）。若该线程正在执行一个非本地Java方法，在PC寄存器的值指示下一条指令执行，该线程在Java内存栈中保存了非本地Java方法调用状态，其状态包括局部变量、被调用的参数、它的返回值、以及中间计算结果。而本地方法调用的状态则是存储在独立的本地方法内存栈里面（native method stacks），这种情况下使得这些本地方法和其他内存运行时数据区的内容尽可能保证和其他内存运行时数据区独立，而且该方法的调用更靠近操作系统，这些方法执行的字节码有可能根据操作系统环境的不同使得其编译出来的本地字节码的结构也有一定的差异。JVM中的内存栈是一个栈帧的组合，一个栈帧包含了某个Java方法调用的状态，当某个线程调用方法的时候，JVM就会将一个新的帧压入到Java内存栈，当方法调用完成过后，JVM将会从内存栈中移除该栈帧。JVM里面不存在一个可以存放中间计算数据结果值的寄存器，其内部指令集使用Java栈空间来存储中间计算的数据结果值，这种做法的设计是为了保持Java虚拟机的指令集紧凑，使得与寄存器原理能够紧密结合并且进行操作。
1)方法区（Method Area）
在JVM实例中，对装载的类型信息是存储在一个逻辑方法内存区中，当Java虚拟机加载了一个类型的时候，它会跟着这个Class的类型去路径里面查找对应的Class文件，类加载器读取类文件（线性二进制数据），然后将该文件传递给Java虚拟机，JVM从二进制数据中提取信息并且将这些信息存储在方法区，而类中声明（静态）变量就是来自于方法区中存储的信息。在JVM里面用什么样的方式存储该信息是由JVM设计的时候决定的，例如：当数据进入方法的时候，多类文件字节的存储量以Big-Endian（第一次最重要的字节）的顺序存储，尽管如此，一个虚拟机可以用任何方式针对这些数据进行存储操作，若它存储在一个Little-Endian处理器上，设计的时候就有可能将多文件字节的值按照Little-Endian顺寻存储。
——【$Big-Endian和Little-Endian】——
程序存储数据过程中，如果数据是跨越多个字节对象就必须有一种约定：
66 它的地址是多少：对于跨越多个字节的对象，一般它所占的字节都是连续的，它的地址等于它所占字节最低地址，这种情况链表可能存储的仅仅是表头
67 它的字节在内存中是如何组织的
比如：int x，它的地址为0x100，那么它占据了内存中的0x100、0x101、0x102、0x103四个字节，所以一般情况我们觉得int是4个字节。上边只是内存组织的一种情况，多字节对象在内存中的组织有两种约定，还有一种情况：若一个整数为W位，它的表示如下：
每一位表示为：[Xw-1,Xw-2,...,X1,X0]
它的最高有效字节MSB（Most Significant Byte）为：[Xw-1,Xw-2,...,Xw-8]
最低有效字节LSB（Least Significant Byte）为：[X7,X6,...,X0]
其余字节则位于LSB和MSB之间
LSB和MSB谁位于内存的最低地址，即代表了该对象的地址，这样就引出了Big-Endian和Little-Endian的问题，如果LSB在MSB前，LSB是最低地址，则该机器是小端，反之则是大端。DES（Digital Equipment Corporation，现在是Compaq公司的一部分）和Intel机器（x86平台）一般采用小端，IBM、Motorola（Power PC）、Sun的机器一般采用大端。当然这种不能代表所有情况，有的CPU既能工作于小端、又可以工作于大端，比如ARM、Alpha、摩托罗拉的PowerPC，这些情况根据具体的处理器型号有所不同。但是大部分操作系统（Windows、FreeBSD、Linux）一般都是Little Endian的，少部分系统（Mac OS）是Big Endian的，所以用什么方式存储还得依赖宿主操作系统环境。
由上图可以看到，映射访问（“写32位地址的0”）主要是由寄存器到内存、由内存到寄存器的一种数据映射方式，Big-Endian在上图可以看出的原子内存单位（Atomic Unit）在系统内存中的增长方向为从左到右，而Little-Endian的地址增长方向为从右到左。举个例子：
若要存储数据0x0A0B0C0D：
Big-Endian：
以8位为一个存储单位，其存储的地址增长为：
上图中可以看出MSB的值存储了0x0A，这种情况下数据的高位是从内存的低地址开始存储的，然后从左到右开始增长，第二位0x0B就是存储在第二位的，如果是按照16位为一个存储单位，其存储方式又为：
则可以看到Big-Endian的映射地址方式为：
MSB：在计算机中，最高有效位（MSB）是指位值的存储位置为转换为二进制数据后的最大值，MSB有时候在Big-Endian的架构中称为最左最大数据位，这种情况下再往左边的内存位则不是数据位了，而是有效位数位置的最高符号位，不仅仅如此，MSB也可以对应一个二进制符号位的符号位补码标记：“1”的含义为负，“0”的含义为正。最高位代表了“最重要字节”，也就是说当某些多字节数据拥有了最大值的时候它就是存储的时候最高位数据的字节对应的内存位置：
Little-Endian：
与Big-Endian相对的就是Little-Endian的存储方式，同样按照8位为一个存储单位上边的数据0x0A0B0C0D存储格式为：
可以看到LSB的值存储的0x0D，也就是数据的最低位是从内存的低地址开始存储的，它的高位是从右到左的顺序逐渐增加内存分配空间进行存储的，如果按照十六位为存储单位存储格式为：
从上图可以看到最低的16位的存储单位里面存储的值为0x0C0D，接着才是0x0A0B，这样就可以看到按照数据从高位到低位在内存中存储的时候是从右到左进行递增存储的，实际上可以从写内存的顺序来理解，实际上数据存储在内存中无非在使用的时候是写内存和读内存，针对LSB的方式最好的书面解释就是向左增加来看待，如果真正在进行内存读写的时候使用这样的顺序，其意义就体现出来了：
按照这种读写格式，0x0D存储在最低内存地址，而从右往左的增长就可以看到LSB存储的数据为0x0D，和初衷吻合，则十六位的存储就可以按照下边的格式来解释：
实际上从上边的存储还会考虑到另外一个问题，如果按照这种方式从右往左的方式进行存储，如果是遇到Unicode文字就和从左到右的语言显示方式相反。比如一个单词“XRAY”，使用Little-Endian的方式存储格式为：
使用这种方式进行内存读写的时候就会发现计算机语言和语言本身的顺序会有冲突，这种冲突主要是以使用语言的人的习惯有关，而书面化的语言从左到右就可以知道其冲突是不可避免的。我们一般使用语言的阅读方式都是从左到右，而低端存储（Little-Endian）的这种内存读写的方式使得我们最终从计算机里面读取字符需要进行倒序，而且考虑另外一个问题，如果是针对中文而言，一个字符是两个字节，就会出现整体顺序和每一个位的顺序会进行两次倒序操作，这种方式真正在制作处理器的时候也存在一种计算上的冲突，而针对使用文字从左到右进行阅读的国家而言，从右到左的方式（Big-Endian）则会有这样的文字冲突，另外一方面，尽管有很多国家使用语言是从右到左，但是仅仅和Big-Endian的方式存在冲突，这些国家毕竟占少数，所以可以理解的是，为什么主流的系统都是使用的Little-Endian的方式
【*：这里不解释Middle-Endian的方式以及Mixed-Endian的方式】
LSB：在计算机中，最低有效位是一个二进制给予单位的整数，位的位置确定了该数据是一个偶数还是奇数，LSB有时被称为最右位。在使用具体位二进制数之内，常见的存储方式就是每一位存储1或者0的方式，从0向上到1每一比特逢二进一的存储方式。LSB的这种特性用来指定单位位，而不是位的数字，而这种方式也有可能产生一定的混乱。
——以上是关于Big-Endian和Little-Endian的简单讲解——
JVM虚拟机将搜索和使用类型的一些信息也存储在方法区中以方便应用程序加载读取该数据。设计者在设计过程也考虑到要方便JVM进行Java应用程序的快速执行，而这种取舍主要是为了程序在运行过程中内存不足的情况能够通过一定的取舍去弥补内存不足的情况。在JVM内部，所有的线程共享相同的方法区，因此，访问方法区的数据结构必须是线程安全的，如果两个线程都试图去调用去找一个名为Lava的类，比如Lava还没有被加载，只有一个线程可以加载该类而另外的线程只能够等待。方法区的大小在分配过程中是不固定的，随着Java应用程序的运行，JVM可以调整其大小，需要注意一点，方法区的内存不需要是连续的，因为方法区内存可以分配在内存堆中，即使是虚拟机JVM实例对象自己所在的内存堆也是可行的，而在实现过程是允许程序员自身来指定方法区的初始化大小的。
同样的，因为Java本身的自动内存管理，方法区也会被垃圾回收的，Java程序可以通过类扩展动态加载器对象，类可以成为“未引用”向垃圾回收器进行申请，如果一个类是“未引用”的，则该类就可能被卸载，
而方法区针对具体的语言特性有几种信息是存储在方法区内的：
【类型信息】：
68 类型的完全限定名（java.lang.String格式）
69 类型的完全限定名的直接父类的完全限定名（除非这个父类的类型是一个接口或者java.lang.Object）
70 不论类型是一个类或者接口
71 类型的修饰符（例如public、abstract、final）
72 任何一个直接超类接口的完全限定名的列表
在JVM和类文件名的内部，类型名一般都是完全限定名（java.lang.String）格式，在Java源文件里面，完全限定名必须加入包前缀，而不是我们在开发过程写的简单类名，而在方法上，只要是符合Java语言规范的类的完全限定名都可以，而JVM可能直接进行解析，比如：（java.lang.String）在JVM内部名称为java/lang/String，这就是我们在异常捕捉的时候经常看到的ClassNotFoundException的异常里面类信息的名称格式。
除此之外，还必须为每一种加载过的类型在JVM内进行存储，下边的信息不存储在方法区内，下边的章节会一一说明
73 类型常量池
74 字段信息
75 方法信息
76 所有定义在Class内部的（静态）变量信息，除开常量
77 一个ClassLoader的引用
78 Class的引用
【常量池】
针对类型加载的类型信息，JVM将这些存储在常量池里，常量池是一个根据类型定义的常量的有序常量集，包括字面量（String、Integer、Float常量）以及符号引用（类型、字段、方法），整个长量池会被JVM的一个索引引用，如同数组里面的元素集合按照索引访问一样，JVM针对这些常量池里面存储的信息也是按照索引方式进行。实际上长量池在Java程序的动态链接过程起到了一个至关重要的作用。
【字段信息】
针对字段的类型信息，下边的信息是存储在方法区里面的：
79 字段名
80 字段类型
81 字段修饰符（public,private,protected,static,final,volatile,transient）
【方法信息】
针对方法信息，下边信息存储在方法区上：
82 方法名
83 方法的返回类型（包括void）
84 方法参数的类型、数目以及顺序
85 方法修饰符（public,private,protected,static,final,synchronized,native,abstract）
针对非本地方法，还有些附加方法信息需要存储在方法区内：
86 方法字节码
87 方法中局部变量区的大小、方法栈帧
88 异常表
【类变量】
类变量在一个类的多个实例之间共享，这些变量直接和类相关，而不是和类的实例相关，（定义过程简单理解为类里面定义的static类型的变量），针对类变量，其逻辑部分就是存储在方法区内的。在JVM使用这些类之前，JVM先要在方法区里面为定义的non-final变量分配内存空间；常量（定义为final）则在JVM内部则不是以同样的方式来进行存储的，尽管针对常量而言，一个final的类变量是拥有它自己的常量池，作为常量池里面的存储某部分，类常量是存储在方法区内的，而其逻辑部分则不是按照上边的类变量的方式来进行内存分配的。虽然non-final类变量是作为这些类型声明中存储数据的某一部分，final变量存储为任何使用它类型的一部分的数据格式进行简单存储。
【ClassLoader引用】
对于每种类型的加载，JVM必须检测其类型是否符合了JVM的语言规范，对于通过类加载器加载的对象类型，JVM必须存储对类的引用，而这些针对类加载器的引用是作为了方法区里面的类型数据部分进行存储的。
【类Class的引用】
JVM在加载了任何一个类型过后会创建一个java.lang.Class的实例，虚拟机必须通过一定的途径来引用该类型对应的一个Class的实例，并且将其存储在方法区内
【方法表】
为了提高访问效率，必须仔细的设计存储在方法区中的数据信息结构。除了以上讨论的结构，jvm的实现者还添加一些其他的数据结构，如方法表【下边会说明】。
2)内存栈（Stack）：
当一个新线程启动的时候，JVM会为Java线程创建每个线程的独立内存栈，如前所言Java的内存栈是由栈帧构成，栈帧本身处于游离状态，在JVM里面，栈帧的操作只有两种：出栈和入栈。正在被线程执行的方法一般称为当前线程方法，而该方法的栈帧就称为当前帧，而在该方法内定义的类称为当前类，常量池也称为当前常量池。当执行一个方法如此的时候，JVM保留当前类和当前常量池的跟踪，当虚拟机遇到了存储在栈帧中的数据上的操作指令的时候，它就执行当前帧的操作。当一个线程调用某个Java方法时，虚拟机创建并且将一个新帧压入到内存堆栈中，而这个压入到内存栈中的帧成为当前栈帧，当该方法执行的时候，JVM使用内存栈来存储参数、局部变量、中间计算结果以及其他相关数据。方法在执行过程有可能因为两种方式而结束：如果一个方法返回完成就属于方法执行的正常结束，如果在这个过程抛出异常而结束，可以称为非正常结束，不论是正常结束还是异常结束，JVM都会弹出或者丢弃该栈帧，则上一帧的方法就成为了当前帧。
在JVM中，Java线程的栈数据是属于某个线程独有的，其他的线程不能够修改或者通过其他方式来访问该线程的栈帧，正因为如此这种情况不用担心多线程同步访问Java的局部变量，当一个线程调用某个方法的时候，方法的局部变量是在方法内部进行的Java栈帧的存储，只有当前线程可以访问该局部变量，而其他线程不能随便访问该内存栈里面存储的数据。内存栈内的栈帧数据和方法区以及内存堆一样，Java栈的栈帧不需要分配在连续的堆栈内，或者说它们可能是在堆，或者两者组合分配，实际数据用于表示Java堆栈和栈帧结构是JVM本身的设计结构决定的，而且在编程过程可以允许程序员指定一个用于Java堆栈的初始大小以及最大、最小尺寸。
【概念区分】
89 内存栈：这里的内存栈和物理结构内存堆栈有点点区别，是内存里面数据存储的一种抽象数据结构。从操作系统上讲，在程序执行过程对内存的使用本身常用的数据结构就是内存堆栈，而这里的内存堆栈指代的就是JVM在使用内存过程整个内存的存储结构，多指内存的物理结构，而Java内存栈不是指代的一个物理结构，更多的时候指代的是一个抽象结构，就是符合JVM语言规范的内存栈的一个抽象结构。因为物理内存堆栈结构和Java内存栈的抽象模型结构本身比较相似，所以我们在学习过程就正常把这两种结构放在一起考虑了，而且二者除了概念上有一点点小的区别，理解成为一种结构对于初学者也未尝不可，所以实际上也可以觉得二者没有太大的本质区别。但是在学习的时候最好分清楚内存堆栈和Java内存栈的一小点细微的差距，前者是物理概念和本身模型，后者是抽象概念和本身模型的一个共同体。而内存堆栈更多的说法可以理解为一个内存块，因为内存块可以通过索引和指针进行数据结构的组合，内存栈就是内存块针对数据结构的一种表示，而内存堆则是内存块的另外一种数据结构的表示，这样理解更容易区分内存栈和内存堆栈（内存块）的概念。
90 栈帧：栈帧是内存栈里面的最小单位，指的是内存栈里面每一个最小内存存储单元，它针对内存栈仅仅做了两个操作：入栈和出栈，一般情况下：所说的堆栈帧和栈帧倒是一个概念，所以在理解上记得加以区分
91 内存堆：这里的内存堆和内存栈是相对应的，其实内存堆里面的数据也是存储在系统内存堆栈里面的，只是它使用了另外一种方式来进行堆里面内存的管理，而本章题目要讲到的就是Java语言本身的内存堆和内存栈，而这两个概念都是抽象的概念模型，而且是相对的。
栈帧：栈帧主要包括三个部分：局部变量、操作数栈帧（操作帧）和帧数据（数据帧）。本地变量和操作数帧的大小取决于需要，这些大小是在编译时就决定的，并且在每个方法的类文件数据中进行分配，帧的数据大小则不一样，它虽然也是在编译时就决定的但是它的大小和本身代码实现有关。当JVM调用一个Java方法的时候，它会检查类的数据来确定在本地变量和操作方法要求的栈大小，它计算该方法所需要的内存大小，然后将这些数据分配好内存空间压入到内存堆栈中。
栈帧——局部变量：局部变量是以Java栈帧组合成为的一个以零为基的数组，使用局部变量的时候使用的实际上是一个包含了0的一个基于索引的数组结构。int类型、float、引用以及返回值都占据了一个数组中的局部变量的条目，而byte、short、char则在存储到局部变量的时候是先转化成为int再进行操作的，则long和double则是在这样一个数组里面使用了两个元素的空间大小，在局部变量里面存储基本数据类型的时候使用的就是这样的结构。举个例子：
class Example3a{
public static int runClassMethod(int i,long l,float f,double d,Object o,byte b)
{
return 0;
}
public int runInstanceMethod(char c,double d,short s,boolean b)
{
return 0;
}
}
栈帧——操作帧：和局部变量一样，操作帧也是一组有组织的数组的存储结构，但是和局部变量不一样的是这个不是通过数组的索引访问的，而是直接进行的入栈和出栈的操作，当操作指令直接压入了操作栈帧过后，从栈帧里面出来的数据会直接在出栈的时候被读取和使用。除了程序计数器以外，操作帧也是可以直接被指令访问到的，JVM里面没有寄存器。处理操作帧的时候Java虚拟机是基于内存栈的而不是基于寄存器的，因为它在操作过程是直接对内存栈进行操作而不是针对寄存器进行操作。而JVM内部的指令也可以来源于其他地方比如紧接着操作符以及操作数的字节码流或者直接从常量池里面进行操作。JVM指令其实真正在操作过程的焦点是集中在内存栈栈帧的操作帧上的。JVM指令将操作帧作为一个工作空间，有许多指令都是从操作帧里面出栈读取的，对指令进行操作过后将操作帧的计算结果重新压入内存堆栈内。比如iadd指令将两个整数压入到操作帧里面，然后将两个操作数进行相加，相加的时候从内存栈里面读取两个操作数的值，然后进行运算，最后将运算结果重新存入到内存堆栈里面。举个简单的例子：
begin
iload_0 //将整数类型的局部变量0压入到内存栈里面
iload_1 //将整数类型的局部变量1压入到内存栈里面
iadd //将两个变量出栈读取，然后进行相加操作，将结果重新压入栈中
istore_2 //将最终输出结果放在另外一个局部变量里面
end
综上所述，就是整个计算过程针对内存的一些操作内容，而整体的结构可以用下图来描述：
栈帧——数据帧：除了局部变量和操作帧以外，Java栈帧还包括了数据帧，用于支持常量池、普通的方法返回以及异常抛出等，这些数据都是存储在Java内存栈帧的数据帧中的。很多JVM的指令集实际上使用的都是常量池里面的一些条目，一些指令，只是把int、long、float、double或者String从常量池里面压入到Java栈帧的操作帧上边，一些指令使用常量池来管理类或者数组的实例化操作、字段的访问控制、或者方法的调用，其他的指令就用来决定常量池条目中记录的某一特定对象是否某一类或者常量池项中指定的接口。常量池会判断类型、字段、方法、类、接口、类字段以及引用是如何在JVM进行符号化描述，而这个过程由JVM本身进行对应的判断。这里就可以理解JVM如何来判断我们通常说的：“原始变量存储在内存栈上，而引用的对象存储在内存堆上边。”除了常量池判断帧数据符号化描述特性以外，这些数据帧必须在JVM正常执行或者异常执行过程辅助它进行处理操作。如果一个方法是正常结束的，JVM必须恢复栈帧调用方法的数据帧，而且必须设置PC寄存器指向调用方法后边等待的指令完成该调用方法的位置。如果该方法存在返回值，JVM也必须将这个值压入到操作帧里面以提供给需要这些数据的方法进行调用。不仅仅如此，数据帧也必须提供一个方法调用的异常表，当JVM在方法中抛出异常而非正常结束的时候，该异常表就用来存放异常信息。
3)内存堆（Heap）：
当一个Java应用程序在运行的时候在程序中创建一个对象或者一个数组的时候，JVM会针对该对象和数组分配一个新的内存堆空间。但是在JVM实例内部，只存在一个内存堆实例，所有的依赖该JVM的Java应用程序都需要共享该堆实例，而Java应用程序本身在运行的时候它自己包含了一个由JVM虚拟机实例分配的自己的堆空间，而在应用程序启动的时候，任何一个Java应用程序都会得到JVM分配的堆空间，而且针对每一个Java应用程序，这些运行Java应用程序的堆空间都是相互独立的。这里所提及到的共享堆实例是指JVM在初始化运行的时候整体堆空间只有一个，这个是Java语言平台直接从操作系统上能够拿到的整体堆空间，所以的依赖该JVM的程序都可以得到这些内存空间，但是针对每一个独立的Java应用程序而言，这些堆空间是相互独立的，每一个Java应用程序在运行最初都是依靠JVM来进行堆空间的分配的。即使是两个相同的Java应用程序，一旦在运行的时候处于不同的操作系统进程（一般为java.exe）中，它们各自分配的堆空间都是独立的，不能相互访问，只是两个Java应用进程初始化拿到的堆空间来自JVM的分配，而JVM是从最初的内存堆实例里面分配出来的。在同一个Java应用程序里面如果出现了不同的线程，则是可以共享每一个Java应用程序拿到的内存堆空间的，这也是为什么在开发多线程程序的时候，针对同一个Java应用程序必须考虑线程安全问题，因为在一个Java进程里面所有的线程是可以共享这个进程拿到的堆空间的数据的。但是Java内存堆有一个特性，就是JVM拥有针对新的对象分配内存的指令，但是它却不包含释放该内存空间的指令，当然开发过程可以在Java源代码中显示释放内存或者说在JVM字节码中进行显示的内存释放，但是JVM仅仅只是检测堆空间中是否有引用不可达（不可以引用）的对象，然后将接下来的操作交给垃圾回收器来处理。
对象表示：
JVM规范里面并没有提及到Java对象如何在堆空间中表示和描述，对象表示可以理解为设计JVM的工程师在最初考虑到对象调用以及垃圾回收器针对对象的判断而独立的一种Java对象在内存中的存储结构，该结构是由设计最初考虑的。针对一个创建的类实例而言，它内部定义的实例变量以及它的超类以及一些相关的核心数据，是必须通过一定的途径进行该对象内部存储以及表示的。当开发过程给定了一个对象引用的时候，JVM必须能够通过这个引用快速从对象堆空间中去拿到该对象能够访问的数据内容。也就是说，堆空间内对象的存储结构必须为外围对象引用提供一种可以访问该对象以及控制该对象的接口使得引用能够顺利地调用该对象以及相关操作。因此，针对堆空间的对象，分配的内存中往往也包含了一些指向方法区的指针，因为从整体存储结构上讲，方法区似乎存储了很多原子级别的内容，包括方法区内最原始最单一的一些变量：比如类字段、字段数据、类型数据等等。而JVM本身针对堆空间的管理存在两种设计结构：
【1】设计一：
堆空间的设计可以划分为两个部分：一个处理池和一个对象池，一个对象的引用可以拿到处理池的一个本地指针，而处理池主要分为两个部分：一个指向对象池里面的指针以及一个指向方法区的指针。这种结构的优势在于JVM在处理对象的时候，更加能够方便地组合堆碎片以使得所有的数据被更加方便地进行调用。当JVM需要将一个对象移动到对象池的时候，它仅仅需要更新该对象的指针到一个新的对象池的内存地址中就可以完成了，然后在处理池中针对该对象的内部结构进行相对应的处理工作。不过这样的方法也会出现一个缺点就是在处理一个对象的时候针对对象的访问需要提供两个不同的指针，这一点可能不好理解，其实可以这样讲，真正在对象处理过程存在一个根据时间戳有区别的对象状态，而对象在移动、更新以及创建的整个过程中，它的处理池里面总是包含了两个指针，一个指针是指向对象内容本身，一个指针是指向了方法区，因为一个完整的对外的对象是依靠这两部分被引用指针引用到的，而我们开发过程是不能够操作处理池的两个指针的，只有引用指针我们可以通过外围编程拿到。如果Java是按照这种设计进行对象存储，这里的引用指针就是平时提及到的“Java的引用”，只是JVM在引用指针还做了一定的封装，这种封装的规则是JVM本身设计的时候做的，它就通过这种结构在外围进行一次封装，比如Java引用不具备直接操作内存地址的能力就是该封装的一种限制规则。这种设计的结构图如下：
【2】设计二：
另外一种堆空间设计就是使用对象引用拿到的本地指针，将该指针直接指向绑定好的对象的实例数据，这些数据里面仅仅包含了一个指向方法区原子级别的数据去拿到该实例相关数据，这种情况下只需要引用一个指针来访问对象实例数据，但是这样的情况使得对象的移动以及对象的数据更新变得更加复杂。当JVM需要移动这些数据以及进行堆内存碎片的整理的时候，就必须直接更新该对象所有运行时的数据区，这种情况可以用下图进行表示：
JVM需要从一个对象引用来获得该引用能够引用的对象数据存在多个原因，当一个程序试图将一个对象的引用转换成为另外一个类型的时候，JVM就会检查两个引用指向的对象是否存在父子类关系，并且检查两个引用引用到的对象是否能够进行类型转换，而且所有这种类型的转换必须执行同样的一个操作：instanceof操作，在上边两种情况下，JVM都必须要去分析引用指向的对象内部的数据。当一个程序调用了一个实例方法的时候，JVM就必须进行动态绑定操作，它必须选择调用方法的引用类型，是一个基于类的方法调用还是一个基于对象的方法调用，要做到这一点，它又要获取该对象的唯一引用才可以。不管对象的实现是使用什么方式来进行对象描述，都是在针对内存中关于该对象的方法表进行操作，因为使用这样的方式加快了实例针对方法的调用，而且在JVM内部实现的时候这样的机制使得其运行表现比较良好，所以方法表的设计在JVM整体结构中发挥了极其重要的作用。关于方法表的存在与否，在JVM规范里面没有严格说明，也有可能真正在实现过程只是一个抽象概念，物理层它根本不存在，针对放发表实现对于一个创建的实例而言，它本身具有不太高的内存需要求，如果该实现里面使用了方法表，则对象的方法表应该是可以很快被外围引用访问到的。
有一种办法就是通过对象引用连接到方法表的时候，如下图：
该图表明，在每个指针指向一个对象的时候，实际上是使用的一个特殊的数据结构，这些特殊的结构包括几个部分：
92 一个指向该对象类所有数据的指针
93 该对象的方法表
实际上从图中可以看出，方法表就是一个指针数组，它的每一个元素包含了一个指针，针对每个对象的方法都可以直接通过该指针在方法区中找到匹配的数据进行相关调用，而这些方法表需要包括的内容如下：
94 方法内存堆栈段空间中操作栈的大小以及局部变量
95 方法字节码
96 一个方法的异常表
这些信息使得JVM足够针对该方法进行调用，在调用过程，这种结构也能够方便子类对象的方法直接通过指针引用到父类的一些方法定义，也就是说指针在内存空间之内通过JVM本身的调用使得父类的一些方法表也可以同样的方式被调用，当然这种调用过程避免不了两个对象之间的类型检查，但是这样的方式就使得继承的实现变得更加简单，而且方法表提供的这些数据足够引用对对象进行带有任何OO特征的对象操作。
另外一种数据在上边的途中没有显示出来，也是从逻辑上讲内存堆中的对象的真实数据结构——对象的锁。这一点可能需要关联到JMM模型中讲的进行理解。JVM中的每一个对象都是和一个锁（互斥）相关联的，这种结构使得该对象可以很容易支持多线程访问，而且该对象的对象锁一次只能被一个线程访问。当一个线程在运行的时候具有某个对象的锁的时候，仅仅只有这个线程可以访问该对象的实例变量，其他线程如果需要访问该实例的实例变量就必须等待这个线程将它占有的对象锁释放过后才能够正常访问，如果一个线程请求了一个被其他线程占有的对象锁，这个请求线程也必须等到该锁被释放过后才能够拿到这个对象的对象锁。一旦这个线程拥有了一个对象锁过后，它自己可以多次向同一个锁发送对象的锁请求，但是如果它要使得被该线程锁住的对象可以被其他锁访问到的话就需要同样的释放锁的次数，比如线程A请求了对象B的对象锁三次，那么A将会一直占有B对象的对象锁，直到它将该对象锁释放了三次。
很多对象也可能在整个生命周期都没有被对象锁锁住过，在这样的情况下对象锁相关的数据是不需要对象内部实现的，除非有线程向该对象请求了对象锁，否则这个对象就没有该对象锁的存储结构。所以上边的实现图可以知道，很多实现不包括指向对象锁的“锁数据”，锁数据的实现必须要等待某个线程向该对象发送了对象锁请求过后，而且是在第一次锁请求过后才会被实现。这个结构中，JVM却能够间接地通过一些办法针对对象的锁进行管理，比如把对象锁放在基于对象地址的搜索树上边。实现了锁结构的对象中，每一个Java对象逻辑上都在内存中成为了一个等待集，这样就使得所有的线程在锁结构里面针对对象内部数据可以独立操作，等待集就使得每个线程能够独立于其他线程去完成一个共同的设计目标以及程序执行的最终结果，这样就使得多线程的线程独享数据以及线程共享数据机制很容易实现。
不仅仅如此，针对内存堆对象还必须存在一个对象的镜像，该镜像的主要目的是提供给垃圾回收器进行监控操作，垃圾回收器是通过对象的状态来判断该对象是否被应用，同样它需要针对堆内的对象进行监控。而当监控过程垃圾回收器收到对象回收的事件触发的时候，虽然使用了不同的垃圾回收算法，不论使用什么算法都需要通过独有的机制来判断对象目前处于哪种状态，然后根据对象状态进行操作。开发过程程序员往往不会去仔细分析当一个对象引用设置成为null了过后虚拟机内部的操作，但实际上Java里面的引用往往不像我们想像中那么简单，Java引用中的虚引用、弱引用就是使得Java引用在显示提交可回收状态的情况下对内存堆中的对象进行的反向监控，这些引用可以监视到垃圾回收器回收该对象的过程。垃圾回收器本身的实现也是需要内存堆中的对象能够提供相对应的数据的。其实这个位置到底JVM里面是否使用了完整的Java对象的镜像还是使用的一个镜像索引我没有去仔细分析过，总之是在堆结构里面存在着堆内对象的一个类似拷贝的镜像机制，使得垃圾回收器能够顺利回收不再被引用的对象。
4)内存栈和内存堆的实现原理探测【该部分为不确定概念】：
实际上不论是内存栈结构、方法区还是内存堆结构，归根到底使用的是操作系统的内存，操作系统的内存结构可以理解为内存块，常用的抽象方式就是一个内存堆栈，而JVM在OS上边安装了过后，就在启动Java程序的时候按照配置文件里面的内容向操作系统申请内存空间，该内存空间会按照JVM内部的方法提供相应的结构调整。
内存栈应该是很容易理解的结构实现，一般情况下，内存栈是保持连续的，但是不绝对，内存栈申请到的地址实际上很多情况下都是连续的，而每个地址的最小单位是按照计算机位来算的，该计算机位里面只有两种状态1和0，而内存栈的使用过程就是典型的类似C++里面的普通指针结构的使用过程，直接针对指针进行++或者--操作就修改了该指针针对内存的偏移量，而这些偏移量就使得该指针可以调用不同的内存栈中的数据。至于针对内存栈发送的指令就是常见的计算机指令，而这些指令就使得该指针针对内存栈的栈帧进行指令发送，比如发送操作指令、变量读取等等，直接就使得内存栈的调用变得更加简单，而且栈帧在接受了该数据过后就知道到底针对栈帧内部的哪一个部分进行调用，是操作帧、数据帧还是局部变量。
内存堆实际上在操作系统里面使用了双向链表的数据结构，双向链表的结构使得即使内存堆不具有连续性，每一个堆空间里面的链表也可以进入下一个堆空间，而操作系统本身在整理内存堆的时候会做一些简单的操作，然后通过每一个内存堆的双向链表就使得内存堆更加方便。而且堆空间不需要有序，甚至说有序不影响堆空间的存储结构，因为它归根到底是在内存块上边进行实现的，内存块本身是一个堆栈结构，只是该内存堆栈里面的块如何分配不由JVM决定，是由操作系统已经最开始分配好了，也就是最小存储单位。然后JVM拿到从操作系统申请的堆空间过后，先进行初始化操作，然后就可以直接使用了。
常见的对程序有影响的内存问题主要是两种：溢出和内存泄漏，上边已经讲过了内存泄漏，其实从内存的结构分析，泄漏这种情况很难甚至说不可能发生在栈空间里面，其主要原因是栈空间本身很难出现悬停的内存，因为栈空间的存储结构有可能是内存的一个地址数组，所以在访问栈空间的时候使用的都是索引或者下标或者就是最原始的出栈和入栈的操作，这些操作使得栈里面很难出现像堆空间一样的内存悬停（也就是引用悬挂）问题。堆空间悬停的内存是因为栈中存放的引用的变化，其实引用可以理解为从栈到堆的一个指针，当该指针发生变化的时候，堆内存碎片就有可能产生，而这种情况下在原始语言里面就经常发生内存泄漏的情况，因为这些悬停的堆空间在系统里面是不能够被任何本地指针引用到，就使得这些对象在未被回收的时候脱离了可操作区域并且占用了系统资源。
栈溢出问题一直都是计算机领域里面的一个安全性问题，这里不做深入讨论，说多了就偏离主题了，而内存泄漏是程序员最容易理解的内存问题，还有一个问题来自于我一个黑客朋友就是：堆溢出现象，这种现象可能更加复杂。
其实Java里面的内存结构，最初看来就是堆和栈的结合，实际上可以这样理解，实际上对象的实际内容才存在对象池里面，而有关对象的其他东西有可能会存储于方法区，而平时使用的时候的引用是存在内存栈上的，这样就更加容易理解它内部的结构，不仅仅如此，有时候还需要考虑到Java里面的一些字段和属性到底是对象域的还是类域的，这个也是一个比较复杂的问题。
二者的区别简单总结一下：
97 管理方式：JVM自己可以针对内存栈进行管理操作，而且该内存空间的释放是编译器就可以操作的内容，而堆空间在Java中JVM本身执行引擎不会对其进行释放操作，而是让垃圾回收器进行自动回收
98 空间大小：一般情况下栈空间相对于堆空间而言比较小，这是由栈空间里面存储的数据以及本身需要的数据特性决定的，而堆空间在JVM堆实例进行分配的时候一般大小都比较大，因为堆空间在一个Java程序中需要存储太多的Java对象数据
99 碎片相关：针对堆空间而言，即使垃圾回收器能够进行自动堆内存回收，但是堆空间的活动量相对栈空间而言比较大，很有可能存在长期的堆空间分配和释放操作，而且垃圾回收器不是实时的，它有可能使得堆空间的内存碎片主键累积起来。针对栈空间而言，因为它本身就是一个堆栈的数据结构，它的操作都是一一对应的，而且每一个最小单位的结构栈帧和堆空间内复杂的内存结构不一样，所以它一般在使用过程很少出现内存碎片。
100 分配方式：一般情况下，栈空间有两种分配方式：静态分配和动态分配，静态分配是本身由编译器分配好了，而动态分配可能根据情况有所不同，而堆空间却是完全的动态分配的，是一个运行时级别的内存分配。而栈空间分配的内存不需要我们考虑释放问题，而堆空间即使在有垃圾回收器的前提下还是要考虑其释放问题。
101 效率：因为内存块本身的排列就是一个典型的堆栈结构，所以栈空间的效率自然比起堆空间要高很多，而且计算机底层内存空间本身就使用了最基础的堆栈结构使得栈空间和底层结构更加符合，它的操作也变得简单就是最简单的两个指令：入栈和出栈；栈空间针对堆空间而言的弱点是灵活程度不够，特别是在动态管理的时候。而堆空间最大的优势在于动态分配，因为它在计算机底层实现可能是一个双向链表结构，所以它在管理的时候操作比栈空间复杂很多，自然它的灵活度就高了，但是这样的设计也使得堆空间的效率不如栈空间，而且低很多。
3.本机内存[部分内容来源于IBM开发中心]
Java堆空间是在编写Java程序中被我们使用得最频繁的内存空间，平时开发过程，开发人员一定遇到过OutOfMemoryError，这种结果有可能来源于Java堆空间的内存泄漏，也可能是因为堆的大小不够而导致的，有时候这些错误是可以依靠开发人员修复的，但是随着Java程序需要处理越来越多的并发程序，可能有些错误就不是那么容易处理了。有些时候即使Java堆空间没有满也可能抛出错误，这种情况下需要了解的就是JRE（Java Runtime Environment）内部到底发生了什么。Java本身的运行宿主环境并不是操作系统，而是Java虚拟机，Java虚拟机本身是用C编写的本机程序，自然它会调用到本机资源，最常见的就是针对本机内存的调用。本机内存是可以用于运行时进程的，它和Java应用程序使用的Java堆内存不一样，每一种虚拟化资源都必须存储在本机内存里面，包括虚拟机本身运行的数据，这样也意味着主机的硬件和操作系统在本机内存的限制将直接影响到Java应用程序的性能。
i.Java运行时如何使用本机内存：
1)堆空间和垃圾回收
Java运行时是一个操作系统进程（Windows下一般为java.exe），该环境提供的功能会受一些位置的用户代码驱动，这虽然提高了运行时在处理资源的灵活性，但是无法预测每种情况下运行时环境需要何种资源，这一点Java堆空间讲解中已经提到过了。在Java命令行可以使用-Xmx和-Xms来控制堆空间初始配置，mx表示堆空间的最大大小，ms表示初始化大小，这也是上提到的启动Java的配置文件可以配置的内容。尽管逻辑内存堆可以根据堆上的对象数量和在GC上花费的时间增加或者减少，但是使用本机内存的大小是保持不变的，而且由-Xms的值指定，大部分GC算法都是依赖被分配的连续内存块的堆空间，因此不能在堆需要扩大的时候分配更多的本机内存，所有的堆内存必须保留下来，请注意这里说的不是Java堆内存空间是本机内存。
本机内存保留和本机内存分配不一样，本机内存被保留的时候，无法使用物理内存或者其他存储器作为备用内存，尽管保留地址空间块不会耗尽物理资源，但是会阻止内存用于其他用途，由保留从未使用过的内存导致的泄漏和泄漏分配的内存造成的问题其严重程度差不多，但使用的堆区域缩小时，一些垃圾回收器会回收堆空间的一部分内容，从而减少物理内存的使用。对于维护Java堆的内存管理系统，需要更多的本机内存来维护它的状态，进行垃圾收集的时候，必须分配数据结构来跟踪空闲存储空间和进度记录，这些数据结构的确切大小和性质因实现的不同而有所差异。
2)JIT
JIT编译器在运行时编译Java字节码来优化本机可执行代码，这样极大提高了Java运行时的速度，并且支持Java应用程序与本地代码相当的速度运行。字节码编译使用本机内存，而且JIT编译器的输入（字节码）和输出（可执行代码）也必须存储在本机内存里面，包含了多个经过JIT编译的方法的Java程序会比一些小型应用程序使用更多的本机内存。
3)类和类加载器
Java 应用程序由一些类组成，这些类定义对象结构和方法逻辑。Java 应用程序也使用 Java 运行时类库（比如 java.lang.String）中的类，也可以使用第三方库。这些类需要存储在内存中以备使用。存储类的方式取决于具体实现。Sun JDK 使用永久生成（permanent generation，PermGen）堆区域，从最基本的层面来看，使用更多的类将需要使用更多内存。（这可能意味着您的本机内存使用量会增加，或者您必须明确地重新设置 PermGen 或共享类缓存等区域的大小，以装入所有类）。记住，不仅您的应用程序需要加载到内存中，框架、应用服务器、第三方库以及包含类的 Java 运行时也会按需加载并占用空间。Java 运行时可以卸载类来回收空间，但是只有在非常严酷的条件下才会这样做，不能卸载单个类，而是卸载类加载器，随其加载的所有类都会被卸载。只有在以下情况下才能卸载类加载器
102 Java 堆不包含对表示该类加载器的 java.lang.ClassLoader 对象的引用。
103 Java 堆不包含对表示类加载器加载的类的任何 java.lang.Class 对象的引用。
104 在 Java 堆上，该类加载器加载的任何类的所有对象都不再存活（被引用）。
需要注意的是，Java 运行时为所有 Java 应用程序创建的 3 个默认类加载器（ bootstrap、extension 和 application ）都不可能满足这些条件，因此，任何系统类（比如 java.lang.String）或通过应用程序类加载器加载的任何应用程序类都不能在运行时释放。即使类加载器适合进行收集，运行时也只会将收集类加载器作为 GC 周期的一部分。一些实现只会在某些 GC 周期中卸载类加载器，也可能在运行时生成类，而不去释放它。许多 Java EE 应用程序使用 JavaServer Pages (JSP) 技术来生成 Web 页面。使用 JSP 会为执行的每个 .jsp 页面生成一个类，并且这些类会在加载它们的类加载器的整个生存期中一直存在 —— 这个生存期通常是 Web 应用程序的生存期。另一种生成类的常见方法是使用 Java 反射。反射的工作方式因 Java 实现的不同而不同，当使用 java.lang.reflect API 时，Java 运行时必须将一个反射对象（比如 java.lang.reflect.Field）的方法连接到被反射到的对象或类。这可以通过使用 Java 本机接口（Java Native Interface，JNI）访问器来完成，这种方法需要的设置很少，但是速度缓慢，也可以在运行时为您想要反射到的每种对象类型动态构建一个类。后一种方法在设置上更慢，但运行速度更快，非常适合于经常反射到一个特定类的应用程序。Java 运行时在最初几次反射到一个类时使用 JNI 方法，但当使用了若干次 JNI 方法之后，访问器会膨胀为字节码访问器，这涉及到构建类并通过新的类加载器进行加载。执行多次反射可能导致创建了许多访问器类和类加载器，保持对反射对象的引用会导致这些类一直存活，并继续占用空间，因为创建字节码访问器非常缓慢，所以 Java 运行时可以缓存这些访问器以备以后使用，一些应用程序和框架还会缓存反射对象，这进一步增加了它们的本机内存占用。
4)JNI
JNI支持本机代码调用Java方法，反之亦然，Java运行时本身极大依赖于JNI代码来实现类库功能，比如文件和网络I/O，JNI应用程序可以通过三种方式增加Java运行时对本机内存的使用：
105 JNI应用程序的本机代码被编译到共享库中，或编译为加载到进程地址空间中的可执行文件，大型本机应用程序可能仅仅加载就会占用大量进程地址空间
106 本机代码必须与Java运行时共享地址空间，任何本机代码分配或本机代码执行的内存映射都会耗用Java运行时内存
107 某些JNI函数可能在它们的常规操作中使用本机内存，GetTypeArrayElements和GetTypeArrayRegion函数可以将Java堆复制到本机内存缓冲区中，提供给本地代码使用，是否复制数据依赖于运行时实现，通过这种方式访问大量Java堆数据就可能使用大量的本机内存堆空间
5)NIO
JDK 1.4开始添加了新的I/O类，引入了一种基于通道和缓冲区执行I/O的新方式，就像Java堆上的内存支持I/O缓冲区一样，NIO添加了对直接ByteBuffer的支持，ByteBuffer受本机内存而不是Java堆的支持，直接ByteBuffer可以直接传递到本机操作系统库函数，以执行I/O，这种情况虽然提高了Java程序在I/O的执行效率，但是会对本机内存进行直接的内存开销。ByteBuffer直接操作和非直接操作的区别如下：
对于在何处存储直接 ByteBuffer 数据，很容易产生混淆。应用程序仍然在 Java 堆上使用一个对象来编排 I/O 操作，但持有该数据的缓冲区将保存在本机内存中，Java 堆对象仅包含对本机堆缓冲区的引用。非直接 ByteBuffer 将其数据保存在 Java 堆上的 byte[] 数组中。直接ByteBuffer对象会自动清理本机缓冲区，但这个过程只能作为Java堆GC的一部分执行，它不会自动影响施加在本机上的压力。GC仅在Java堆被填满，以至于无法为堆分配请求提供服务的时候，或者在Java应用程序中显示请求它发生。
6)线程：
应用程序中的每个线程都需要内存来存储器堆栈（用于在调用函数时持有局部变量并维护状态的内存区域）。每个 Java 线程都需要堆栈空间来运行。根据实现的不同，Java 线程可以分为本机线程和 Java 堆栈。除了堆栈空间，每个线程还需要为线程本地存储（thread-local storage）和内部数据结构提供一些本机内存。尽管每个线程使用的内存量非常小，但对于拥有数百个线程的应用程序来说，线程堆栈的总内存使用量可能非常大。如果运行的应用程序的线程数量比可用于处理它们的处理器数量多，效率通常很低，并且可能导致糟糕的性能和更高的内存占用。
ii.本机内存耗尽：
Java运行时善于以不同的方式来处理Java堆空间的耗尽和本机堆空间的耗尽，但是这两种情形具有类似症状，当Java堆空间耗尽的时候，Java应用程序很难正常运行，因为Java应用程序必须通过分配对象来完成工作，只要Java堆被填满，就会出现糟糕的GC性能，并且抛出OutOfMemoryError。相反，一旦 Java 运行时开始运行并且应用程序处于稳定状态，它可以在本机堆完全耗尽之后继续正常运行，不一定会发生奇怪的行为，因为需要分配本机内存的操作比需要分配 Java 堆的操作少得多。尽管需要本机内存的操作因 JVM 实现不同而异，但也有一些操作很常见：启动线程、加载类以及执行某种类型的网络和文件 I/O。本机内存不足行为与 Java 堆内存不足行为也不太一样，因为无法对本机堆分配进行控制，尽管所有 Java 堆分配都在 Java 内存管理系统控制之下，但任何本机代码（无论其位于 JVM、Java 类库还是应用程序代码中）都可能执行本机内存分配，而且会失败。尝试进行分配的代码然后会处理这种情况，无论设计人员的意图是什么：它可能通过 JNI 接口抛出一个 OutOfMemoryError，在屏幕上输出一条消息，发生无提示失败并在稍后再试一次，或者执行其他操作。
iii.例子：
这篇文章一致都在讲概念，这里既然提到了ByteBuffer，先提供一个简单的例子演示该类的使用：
——[$]使用NIO读取txt文件——
package org.susan.java.io;
import java.io.FileInputStream;
import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
public class ExplicitChannelRead {
public static void main(String args[]){
FileInputStream fileInputStream;
FileChannel fileChannel;
long fileSize;
ByteBuffer byteBuffer;
try{
fileInputStream = new FileInputStream("D://read.txt");
fileChannel = fileInputStream.getChannel();
fileSize = fileChannel.size();
byteBuffer = ByteBuffer.allocate((int)fileSize);
fileChannel.read(byteBuffer);
byteBuffer.rewind();
for( int i = 0; i < fileSize; i++ )
System.out.print((char)byteBuffer.get());
fileChannel.close();
fileInputStream.close();
}catch(IOException ex){
ex.printStackTrace();
}
}
}
在读取文件的路径放上该txt文件里面写入：Hello World，上边这段代码就是使用NIO的方式读取文件系统上的文件，这段程序的输入就为：
Hello World
——[$]获取ByteBuffer上的字节转换为Byte数组——
package org.susan.java.io;
import java.nio.ByteBuffer;
public class ByteBufferToByteArray {
public static void main(String args[]) throws Exception{
// 从byte数组创建ByteBuffer
byte[] bytes = new byte[10];
ByteBuffer buffer = ByteBuffer.wrap(bytes);
// 在position和limit，也就是ByteBuffer缓冲区的首尾之间读取字节
bytes = new byte[buffer.remaining()];
buffer.get(bytes, 0, bytes.length);
// 读取所有ByteBuffer内的字节
buffer.clear();
bytes = new byte[buffer.capacity()];
buffer.get(bytes, 0, bytes.length);
}
}
上边代码就是从ByteBuffer到byte数组的转换过程，有了这个过程在开发过程中可能更加方便，ByteBuffer的详细讲解我保留到IO部分，这里仅仅是涉及到了一些，所以提供两段实例代码。
iv.共享内存：
在Java语言里面，没有共享内存的概念，但是在某些引用中，共享内存却很受用，例如Java语言的分布式系统，存着大量的Java分布式共享对象，很多时候需要查询这些对象的状态，以查看系统是否运行正常或者了解这些对象目前的一些统计数据和状态。如果使用的是网络通信的方式，显然会增加应用的额外开销，也增加了不必要的应用编程，如果是共享内存方式，则可以直接通过共享内存查看到所需要的对象的数据和统计数据，从而减少一些不必要的麻烦。
1)共享内存特点：
108 可以被多个进程打开访问
109 读写操作的进程在执行读写操作的时候其他进程不能进行写操作
110 多个进程可以交替对某一个共享内存执行写操作
111 一个进程执行了内存写操作过后，不影响其他进程对该内存的访问，同时其他进程对更新后的内存具有可见性
112 在进程执行写操作时如果异常退出，对其他进程的写操作禁止自动解除
113 相对共享文件，数据访问的方便性和效率
2)出现情况：
114 独占的写操作，相应有独占的写操作等待队列。独占的写操作本身不会发生数据的一致性问题；
115 共享的写操作，相应有共享的写操作等待队列。共享的写操作则要注意防止发生数据的一致性问题；
116 独占的读操作，相应有共享的读操作等待队列；
117 共享的读操作，相应有共享的读操作等待队列；
3)Java中共享内存的实现：
JDK 1.4里面的MappedByteBuffer为开发人员在Java中实现共享内存提供了良好的方法，该缓冲区实际上是一个磁盘文件的内存映象，二者的变化会保持同步，即内存数据发生变化过后会立即反应到磁盘文件中，这样会有效地保证共享内存的实现，将共享文件和磁盘文件简历联系的是文件通道类：FileChannel，该类的加入是JDK为了统一外围设备的访问方法，并且加强了多线程对同一文件进行存取的安全性，这里可以使用它来建立共享内存用，它建立了共享内存和磁盘文件之间的一个通道。打开一个文件可使用RandomAccessFile类的getChannel方法，该方法直接返回一个文件通道，该文件通道由于对应的文件设为随机存取，一方面可以进行读写两种操作，另外一个方面使用它不会破坏映象文件的内容。这里，如果使用FileOutputStream和FileInputStream则不能理想地实现共享内存的要求，因为这两个类同时实现自由读写很困难。
下边代码段实现了上边提及的共享内存功能
// 获得一个只读的随机存取文件对象
RandomAccessFile RAFile = new RandomAccessFile(filename,"r");
// 获得相应的文件通道
FileChannel fc = RAFile.getChannel();
// 取得文件的实际大小
int size = (int)fc.size();
// 获得共享内存缓冲区，该共享内存只读
MappedByteBuffer mapBuf = fc.map(FileChannel.MAP_RO,0,size);
// 获得一个可读写的随机存取文件对象
RAFile = new RandomAccessFile(filename,"rw");
// 获得相应的文件通道
fc = RAFile.getChannel();
// 取得文件的实际大小，以便映像到共享内存
size = (int)fc.size();
// 获得共享内存缓冲区，该共享内存可读写
mapBuf = fc.map(FileChannel.MAP_RW,0,size);
// 获取头部消息：存取权限
mode = mapBuf.getInt();
如果多个应用映象使用同一文件名的共享内存，则意味着这多个应用共享了同一内存数据，这些应用对于文件可以具有同等存取权限，一个应用对数据的刷新会更新到多个应用中。为了防止多个应用同时对共享内存进行写操作，可以在该共享内存的头部信息加入写操作标记，该共享文件的头部基本信息至少有：
118 共享内存长度
119 共享内存目前的存取模式
共享文件的头部信息是私有信息，多个应用可以对同一个共享内存执行写操作，执行写操作和结束写操作的时候，可以使用如下方法：
public boolean startWrite()
{
if(mode == 0) // 这里mode代表共享内存的存取模式，为0代表可写
{
mode = 1; // 意味着别的应用不可写
mapBuf.flip();
mapBuf.putInt(mode); //写入共享内存的头部信息
return true;
}
else{
return false; //表明已经有应用在写该共享内存了，本应用不能够针对共享内存再做写操作
}
}
public boolean stopWrite()
{
mode = 0; // 释放写权限
mapBuf.flip();
mapBuf.putInt(mode); //写入共享内存头部信息
return true;
}
【*：上边提供了对共享内存执行写操作过程的两个方法，这两个方法其实理解起来很简单，真正需要思考的是一个针对存取模式的设置，其实这种机制和最前面提到的内存的锁模式有点类似，一旦当mode（存取模式）设置称为可写的时候，startWrite才能返回true，不仅仅如此，某个应用程序在向共享内存写入数据的时候还会修改其存取模式，因为如果不修改的话就会导致其他应用同样针对该内存是可写的，这样就使得共享内存的实现变得混乱，而在停止写操作stopWrite的时候，需要将mode设置称为1，也就是上边注释段提到的释放写权限。】
关于锁的知识这里简单做个补充【*：上边代码的这种模式可以理解为一种简单的锁模式】：一般情况下，计算机编程中会经常遇到锁模式，在整个锁模式过程中可以将锁分为两类（这里只是辅助理解，不是严格的锁分类）——共享锁和排他锁（也称为独占锁），锁的定位是定位于针对所有与计算机有关的资源比如内存、文件、存储空间等，针对这些资源都可能出现锁模式。在上边堆和栈一节讲到了Java对象锁，其实不仅仅是对象，只要是计算机中会出现写入和读取共同操作的资源，都有可能出现锁模式。
共享锁——当应用程序获得了资源的共享锁的时候，那么应用程序就可以直接访问该资源，资源的共享锁可以被多个应用程序拿到，在Java里面线程之间有时候也存在对象的共享锁，但是有一个很明显的特征，也就是内存共享锁只能读取数据，不能够写入数据，不论是什么资源，当应用程序仅仅只能拿到该资源的共享锁的时候，是不能够针对该资源进行写操作的。
独占锁——当应用程序获得了资源的独占锁的时候，应用程序访问该资源在共享锁上边多了一个权限就是写权限，针对资源本身而言，一个资源只有一把独占锁，也就是说一个资源只能同时被一个应用或者一个执行代码程序允许写操作，Java线程中的对象写操作也是这个道理，若某个应用拿到了独占锁的时候，不仅仅可以读取资源里面的数据，而且可以向该资源进行数据写操作。
数据一致性——当资源同时被应用进行读写访问的时候，有可能会出现数据一致性问题，比如A应用拿到了资源R1的独占锁，B应用拿到了资源R1的共享锁，A在针对R1进行写操作，而两个应用的操作——A的写操作和B的读操作出现了一个时间差，s1的时候B读取了R1的资源，s2的时候A写入了数据修改了R1的资源，s3的时候B又进行了第二次读，而两次读取相隔时间比较短暂而且初衷没有考虑到A在B的读取过程修改了资源，这种情况下针对锁模式就需要考虑到数据一致性问题。独占锁的排他性在这里的意思是该锁只能被一个应用获取，获取过程只能由这个应用写入数据到资源内部，除非它释放该锁，否则其他拿不到锁的应用是无法对资源进行写入操作的。
按照上边的思路去理解代码里面实现共享内存的过程就更加容易理解了。
如果执行写操作的应用异常中止，那么映像文件的共享内存将不再能执行写操作。为了在应用异常中止后，写操作禁止标志自动消除，必须让运行的应用获知退出的应用。在多线程应用中，可以用同步方法获得这样的效果，但是在多进程中，同步是不起作用的。方法可以采用的多种技巧，这里只是描述一可能的实现：采用文件锁的方式。写共享内存应用在获得对一个共享内存写权限的时候，除了判断头部信息的写权限标志外，还要判断一个临时的锁文件是否可以得到，如果可以得到，则即使头部信息的写权限标志为1（上述），也可以启动写权限，其实这已经表明写权限获得的应用已经异常退出，这段代码如下：
// 打开一个临时文件，注意统一共享内存，该文件名必须相同，可以在共享文件名后边添加“.lock”后缀
RandomAccessFile files = new RandomAccessFile("memory.lock","rw");
// 获取文件通道
FileChannel lockFileChannel = files.getChannel();
// 获取文件的独占锁，该方法不产生任何阻塞直接返回
FileLock fileLock = lockFileChannel.tryLock();
// 如果为空表示已经有应用占有了
if( fileLock == null ){
// ...不可写
}else{
// ...可以执行写操作
}
4)共享内存的应用：
在Java中，共享内存一般有两种应用：
[1]永久对象配置——在java服务器应用中，用户可能会在运行过程中配置一些参数，而这些参数需要永久 有效，当服务器应用重新启动后，这些配置参数仍然可以对应用起作用。这就可以用到该文 中的共享内存。该共享内存中保存了服务器的运行参数和一些对象运行特性。可以在应用启动时读入以启用以前配置的参数。
[2]查询共享数据——一个应用（例 sys.java）是系统的服务进程，其系统的运行状态记录在共享内存中，其中运行状态可能是不断变化的。为了随时了解系统的运行状态，启动另一个应用（例 mon.java），该应用查询该共享内存，汇报系统的运行状态。
v.小节：
提供本机内存以及共享内存的知识，主要是为了让读者能够更顺利地理解JVM内部内存模型的物理原理，包括JVM如何和操作系统在内存这个级别进行交互，理解了这些内容就让读者对Java内存模型的认识会更加深入，而且不容易遗忘。其实Java的内存模型远不及我们想象中那么简单，而且其结构极端复杂，看过《Inside JVM》的朋友应该就知道，结合JVM指令集去写点小代码测试.class文件的里层结构也不失为一种好玩的学习方法。
4.防止内存泄漏
Java中会有内存泄漏，听起来似乎是很不正常的，因为Java提供了垃圾回收器针对内存进行自动回收，但是Java还是会出现内存泄漏的。
i.什么是Java中的内存泄漏：
在Java语言中，内存泄漏就是存在一些被分配的对象，这些对象有两个特点：这些对象可达，即在对象内存的有向图中存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象了。如果对象满足这两个条件，该对象就可以判定为Java中的内存泄漏，这些对象不会被GC回收，然而它却占用内存，这就是Java语言中的内存泄漏。Java中的内存泄漏和C++中的内存泄漏还存在一定的区别，在C++里面，内存泄漏的范围更大一些，有些对象被分配了内存空间，但是却不可达，由于C++中没有GC，这些内存将会永远收不回来，在Java中这些不可达对象则是被GC负责回收的，因此程序员不需要考虑这一部分的内存泄漏。二者的图如下：
因此按照上边的分析，Java语言中也是存在内存泄漏的，但是其内存泄漏范围比C++要小很多，因为Java里面有个特殊程序回收所有的不可达对象：垃圾回收器。对于程序员来说，GC基本是透明的，不可见的。虽然，我们只有几个函数可以访问GC，例如运行GC的函数System.gc()，但是根据Java语言规范定义，该函数不保证JVM的垃圾收集器一定会执行。因为，不同的JVM实现者可能使用不同的算法管理GC。通常，GC的线程的优先级别较低，JVM调用GC的策略也有很多种，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是平缓执行GC，有的是中断式执行GC。但通常来说，我们不需要关心这些。除非在一些特定的场合，GC的执行影响应用程序的性能，例如对于基于Web的实时系统，如网络游戏等，用户不希望GC突然中断应用程序执行而进行垃圾回收，那么我们需要调整GC的参数，让GC能够通过平缓的方式释放内存，例如将垃圾回收分解为一系列的小步骤执行，Sun提供的HotSpot JVM就支持这一特性。
举个例子：
——[$]内存泄漏的例子——
package org.susan.java.collection;
import java.util.Vector;
public class VectorMemoryLeak {
public static void main(String args[]){
Vector<String> vector = new Vector<String>();
for( int i = 0; i < 1000; i++ ){
String tempString = new String();
vector.add(tempString);
tempString = null;
}
}
}
从上边这个例子可以看到，循环申请了String对象，并且将申请的对象放入了一个Vector中，如果仅仅是释放对象本身，因为Vector仍然引用了该对象，所以这个对象对CG来说是不可回收的，因此如果对象加入到Vector后，还必须从Vector删除才能够回收，最简单的方式是将Vector引用设置成null。实际上这些对象已经没有用了，但是还是被代码里面的引用引用到了，这种情况GC拿它就没有了任何办法，这样就可以导致了内存泄漏。
【*：Java语言因为提供了垃圾回收器，照理说是不会出现内存泄漏的，Java里面导致内存泄漏的主要原因就是，先前申请了内存空间而忘记了释放。如果程序中存在对无用对象的引用，这些对象就会驻留在内存中消耗内存，因为无法让GC判断这些对象是否可达。如果存在对象的引用，这个对象就被定义为“有效的活动状态”，同时不会被释放，要确定对象所占内存被回收，必须要确认该对象不再被使用。典型的做法就是把对象数据成员设置成为null或者中集合中移除，当局部变量不需要的情况则不需要显示声明为null。】
ii.常见的Java内存泄漏
1)全局集合：
在大型应用程序中存在各种各样的全局数据仓库是很普遍的，比如一个JNDI树或者一个Session table（会话表），在这些情况下，必须注意管理存储库的大小，必须有某种机制从存储库中移除不再需要的数据。
[$]解决：
[1]常用的解决方法是周期运作清除作业，该作业会验证仓库中的数据然后清楚一切不需要的数据
[2]另外一种方式是反向链接计数，集合负责统计集合中每个入口的反向链接数据，这要求反向链接告诉集合合适会退出入口，当反向链接数目为零的时候，该元素就可以移除了。
2)缓存：
缓存一种用来快速查找已经执行过的操作结果的数据结构。因此，如果一个操作执行需要比较多的资源并会多次被使用，通常做法是把常用的输入数据的操作结果进行缓存，以便在下次调用该操作时使用缓存的数据。缓存通常都是以动态方式实现的,如果缓存设置不正确而大量使用缓存的话则会出现内存溢出的后果，因此需要将所使用的内存容量与检索数据的速度加以平衡。
[$]解决：
[1]常用的解决途径是使用java.lang.ref.SoftReference类坚持将对象放入缓存，这个方法可以保证当虚拟机用完内存或者需要更多堆的时候，可以释放这些对象的引用。
3)类加载器：
Java类装载器的使用为内存泄漏提供了许多可乘之机。一般来说类装载器都具有复杂结构，因为类装载器不仅仅是只与"常规"对象引用有关，同时也和对象内部的引用有关。比如数据变量，方法和各种类。这意味着只要存在对数据变量，方法，各种类和对象的类装载器，那么类装载器将驻留在JVM中。既然类装载器可以同很多的类关联，同时也可以和静态数据变量关联，那么相当多的内存就可能发生泄漏。
iii.Java引用【摘录自前边的《Java引用总结》】：
Java中的对象引用主要有以下几种类型：
1)强可及对象（strongly reachable）：
可以通过强引用访问的对象，一般来说，我们平时写代码的方式都是使用的强引用对象，比如下边的代码段：
StringBuilder builder= new StringBuilder()；
上边代码部分引用obj这个引用将引用内存堆中的一个对象，这种情况下，只要obj的引用存在，垃圾回收器就永远不会释放该对象的存储空间。这种对象我们又成为强引用（Strong references），这种强引用方式就是Java语言的原生的Java引用，我们几乎每天编程的时候都用到。上边代码JVM存储了一个StringBuilder类型的对象的强引用在变量builder呢。强引用和GC的交互是这样的，如果一个对象通过强引用可达或者通过强引用链可达的话这种对象就成为强可及对象，这种情况下的对象垃圾回收器不予理睬。如果我们开发过程不需要垃圾回器回收该对象，就直接将该对象赋为强引用，也是普通的编程方法。
2)软可及对象（softly reachable）：
不通过强引用访问的对象，即不是强可及对象，但是可以通过软引用访问的对象就成为软可及对象，软可及对象就需要使用类SoftReference（java.lang.ref.SoftReference）。此种类型的引用主要用于内存比较敏感的高速缓存，而且此种引用还是具有较强的引用功能，当内存不够的时候GC会回收这类内存，因此如果内存充足的时候，这种引用通常不会被回收的。不仅仅如此，这种引用对象在JVM里面保证在抛出OutOfMemory异常之前，设置成为null。通俗地讲，这种类型的引用保证在JVM内存不足的时候全部被清除，但是有个关键在于：垃圾收集器在运行时是否释放软可及对象是不确定的，而且使用垃圾回收算法并不能保证一次性寻找到所有的软可及对象。当垃圾回收器每次运行的时候都可以随意释放不是强可及对象占用的内存，如果垃圾回收器找到了软可及对象过后，可能会进行以下操作：
120 将SoftReference对象的referent域设置成为null，从而使该对象不再引用heap对象。
121 SoftReference引用过的内存堆上的对象一律被生命为finalizable。
122 当内存堆上的对象finalize()方法被运行而且该对象占用的内存被释放，SoftReference对象就会被添加到它的ReferenceQueue，前提条件是ReferenceQueue本身是存在的。
既然Java里面存在这样的对象，那么我们在编写代码的时候如何创建这样的对象呢？创建步骤如下：
先创建一个对象，并使用普通引用方式【强引用】，然后再创建一个SoftReference来引用该对象，最后将普通引用设置为null，通过这样的方式，这个对象就仅仅保留了一个SoftReference引用，同时这种情况我们所创建的对象就是SoftReference对象。一般情况下，我们可以使用该引用来完成Cache功能，就是前边说的用于高速缓存，保证最大限度使用内存而不会引起内存泄漏的情况。下边的代码段：
public static void main(String args[])
{
//创建一个强可及对象
A a = new A();
//创建这个对象的软引用SoftReference
SoftReference sr = new SoftReference(a);
//将强引用设置为空，以遍垃圾回收器回收强引用
a = null;
//下次使用该对象的操作
if( sr != null ){
a = (A)sr.get();
}else{
//这种情况就是由于内存过低，已经将软引用释放了，因此需要重新装载一次
a = new A();
sr = new SoftReference(a);
}
}
软引用技术使得Java系统可以更好地管理内存，保持系统稳定，防止内存泄漏，避免系统崩溃，因此在处理一些内存占用大而且生命周期长使用不频繁的对象可以使用该技术。
3)弱可及对象（weakly reachable）：
不是强可及对象同样也不是软可及对象，仅仅通过弱引用WeakReference（java.lang.ref.WeakReference）访问的对象，这种对象的用途在于规范化映射（canonicalized mapping），对于生存周期相对比较长而且重新创建的时候开销少的对象，弱引用也比较有用，和软引用对象不同的是，垃圾回收器如果碰到了弱可及对象，将释放WeakReference对象的内存，但是垃圾回收器需要运行很多次才能够找到弱可及对象。弱引用对象在使用的时候，可以配合ReferenceQueue类使用，如果弱引用被回收，JVM就会把这个弱引用加入到相关的引用队列中去。最简单的弱引用方法如以下代码：
WeakReference weakWidget = new WeakReference(classA);
在上边代码里面，当我们使用weakWidget.get()来获取classA的时候，由于弱引用本身是无法阻止垃圾回收的，所以我们也许会拿到一个null为返回。【*：这里提供一个小技巧，如果我们希望取得某个对象的信息，但是又不影响该对象的垃圾回收过程，我们就可以使用WeakReference来记住该对象，一般我们在开发调试器和优化器的时候使用这个是很好的一个手段。】
如果上边的代码部分，我们通过weakWidget.get()返回的是null就证明该对象已经被垃圾回收器回收了，而这种情况下弱引用对象就失去了使用价值，GC就会定义为需要进行清除工作。这种情况下弱引用无法引用任何对象，所以在JVM里面就成为了一个死引用，这就是为什么我们有时候需要通过ReferenceQueue类来配合使用的原因，使用了ReferenceQueue过后，就使得我们更加容易监视该引用的对象，如果我们通过一ReferenceQueue类来构造一个弱引用，当弱引用的对象已经被回收的时候，系统将自动使用对象引用队列来代替对象引用，而且我们可以通过ReferenceQueue类的运行来决定是否真正要从垃圾回收器里面将该死引用（Dead Reference）清除。
弱引用代码段：
//创建普通引用对象
MyObject object = new MyObject();
//创建一个引用队列
ReferenceQueue rq = new ReferenceQueue();
//使用引用队列创建MyObject的弱引用
WeakReference wr = new WeakReference(object,rq);
这里提供两个实在的场景来描述弱引用的相关用法：
[1]你想给对象附加一些信息，于是你用一个 Hashtable 把对象和附加信息关联起来。你不停的把对象和附加信息放入 Hashtable 中，但是当对象用完的时候，你不得不把对象再从 Hashtable 中移除，否则它占用的内存变不会释放。万一你忘记了，那么没有从 Hashtable 中移除的对象也可以算作是内存泄漏。理想的状况应该是当对象用完时，Hashtable 中的对象会自动被垃圾收集器回收，不然你就是在做垃圾回收的工作。
[2]你想实现一个图片缓存，因为加载图片的开销比较大。你将图片对象的引用放入这个缓存，以便以后能够重新使用这个对象。但是你必须决定缓存中的哪些图片不再需要了，从而将引用从缓存中移除。不管你使用什么管理缓存的算法，你实际上都在处理垃圾收集的工作，更简单的办法（除非你有特殊的需求，这也应该是最好的办法）是让垃圾收集器来处理，由它来决定回收哪个对象。
当Java回收器遇到了弱引用的时候有可能会执行以下操作：
123 将WeakReference对象的referent域设置成为null，从而使该对象不再引用heap对象。
124 WeakReference引用过的内存堆上的对象一律被生命为finalizable。
125 当内存堆上的对象finalize()方法被运行而且该对象占用的内存被释放，WeakReference对象就会被添加到它的ReferenceQueue，前提条件是ReferenceQueue本身是存在的。
4)清除：
当引用对象的referent域设置为null，并且引用类在内存堆中引用的对象声明为可结束的时候，该对象就可以清除，清除不做过多的讲述
5)虚可及对象（phantomly reachable）：
不是强可及对象，也不是软可及对象，同样不是弱可及对象，之所以把虚可及对象放到最后来讲，主要也是因为它的特殊性，有时候我们又称之为“幽灵对象”，已经结束的，可以通过虚引用来访问该对象。我们使用类PhantomReference（java.lang.ref.PhantomReference）来访问，这个类只能用于跟踪被引用对象进行的收集，同样的，可以用于执行per-mortern清除操作。PhantomReference必须与ReferenceQueue类一起使用。需要使用ReferenceQueue是因为它能够充当通知机制，当垃圾收集器确定了某个对象是虚可及对象的时候，PhantomReference对象就被放在了它的ReferenceQueue上，这就是一个通知，表明PhantomReference引用的对象已经结束，可以收集了，一般情况下我们刚好在对象内存在回收之前采取该行为。这种引用不同于弱引用和软引用，这种方式通过get()获取到的对象总是返回null，仅仅当这些对象在ReferenceQueue队列里面的时候，我们可以知道它所引用的哪些对对象是死引用（Dead Reference）。而这种引用和弱引用的区别在于：
弱引用（WeakReference）是在对象不可达的时候尽快进入ReferenceQueue队列的，在finalization方法执行和垃圾回收之前是确实会发生的，理论上这类对象是不正确的对象，但是WeakReference对象可以继续保持Dead状态，
虚引用（PhantomReference）是在对象确实已经从物理内存中移除过后才进入的ReferenceQueue队列，而且get()方法会一直返回null
当垃圾回收器遇到了虚引用的时候将有可能执行以下操作：
126 PhantomReference引用过的heap对象声明为finalizable；
127 虚引用在堆对象释放之前就添加到了它的ReferenceQueue里面，这种情况使得我们可以在堆对象被回收之前采取操作【*：再次提醒，PhantomReference对象必须经过关联的ReferenceQueue来创建，就是说必须和ReferenceQueue类配合操作】
看似没有用处的虚引用，有什么用途呢？
128 首先，我们可以通过虚引用知道对象究竟什么时候真正从内存里面移除的，而且这也是唯一的途径。
129 虚引用避过了finalize()方法，因为对于此方法的执行而言，虚引用真正引用到的对象是异常对象，若在该方法内要使用对象只能重建。一般情况垃圾回收器会轮询两次，一次标记为finalization，第二次进行真实的回收，而往往标记工作不能实时进行，或者垃圾回收其会等待一个对象去标记finalization。这种情况很有可能引起MemoryOut，而使用虚引用这种情况就会完全避免。因为虚引用在引用对象的过程不会去使得这个对象由Dead复活，而且这种对象是可以在回收周期进行回收的。
在JVM内部，虚引用比起使用finalize()方法更加安全一点而且更加有效。而finaliaze()方法回收在虚拟机里面实现起来相对简单，而且也可以处理大部分工作，所以我们仍然使用这种方式来进行对象回收的扫尾操作，但是有了虚引用过后我们可以选择是否手动操作该对象使得程序更加高效完美。
iv.防止内存泄漏[来自IBM开发中心]：
1)使用软引用阻止泄漏：
[1]在Java语言中有一种形式的内存泄漏称为对象游离（Object Loitering）：
——[$]对象游离——
// 注意，这段代码属于概念说明代码，实际应用中不要模仿
public class LeakyChecksum{
private byte[] byteArray;
public synchronized int getFileCheckSum(String filename)
{
int len = getFileSize(filename);
if( byteArray == null || byteArray.length < len )
byteArray = new byte[len];
readFileContents(filename,byteArray);
// 计算该文件的值然后返回该对象
}
}
上边的代码是类LeakyChecksum用来说明对象游离的概念，里面有一个getFileChecksum()方法用来计算文件内容校验和，getFileCheckSum方法将文件内容读取到缓冲区中计算校验和，更加直观的实现就是简单地将缓冲区作为getFileChecksum中的本地变量分配，但是上边这个版本比这种版本更加“聪明”，不是将缓冲区缓冲在实例中字段中减少内存churn。该“优化”通常不带来预期的好处，对象分配比很多人期望的更加便宜。（还要注意，将缓冲区从本地变量提升到实例变量，使得类若不带有附加的同步，就不再是线程安全的了。直观的实现不需要将 getFileChecksum() 声明为 synchronized，并且会在同时调用时提供更好的可伸缩性。）
这个类存在很多的问题，但是我们着重来看内存泄漏。缓存缓冲区的决定很可能是根据这样的假设得出的，即该类将在一个程序中被调用许多次，因此它应该更加有效，以重用缓冲区而不是重新分配它。但是结果是，缓冲区永远不会被释放，因为它对程序来说总是可及的（除非LeakyChecksum对象被垃圾收集了）。更坏的是，它可以增长，却不可以缩小，所以 LeakyChecksum 将永久保持一个与所处理的最大文件一样大小的缓冲区。退一万步说，这也会给垃圾收集器带来压力，并且要求更频繁的收集；为计算未来的校验和而保持一个大型缓冲区并不是可用内存的最有效利用。LeakyChecksum 中问题的原因是，缓冲区对于 getFileChecksum() 操作来说逻辑上是本地的，但是它的生命周期已经被人为延长了，因为将它提升到了实例字段。因此，该类必须自己管理缓冲区的生命周期，而不是让 JVM 来管理。
这里可以提供一种策略就是使用Java里面的软引用：
弱引用如何可以给应用程序提供当对象被程序使用时另一种到达该对象的方法，但是不会延长对象的生命周期。Reference 的另一个子类——软引用——可满足一个不同却相关的目的。其中弱引用允许应用程序创建不妨碍垃圾收集的引用，软引用允许应用程序通过将一些对象指定为 “expendable” 而利用垃圾收集器的帮助。尽管垃圾收集器在找出哪些内存在由应用程序使用哪些没在使用方面做得很好，但是确定可用内存的最适当使用还是取决于应用程序。如果应用程序做出了不好的决定，使得对象被保持，那么性能会受到影响，因为垃圾收集器必须更加辛勤地工作，以防止应用程序消耗掉所有内存。高速缓存是一种常见的性能优化，允许应用程序重用以前的计算结果，而不是重新进行计算。高速缓存是 CPU 利用和内存使用之间的一种折衷，这种折衷理想的平衡状态取决于有多少内存可用。若高速缓存太少，则所要求的性能优势无法达到；若太多，则性能会受到影响，因为太多的内存被用于高速缓存上，导致其他用途没有足够的可用内存。因为垃圾收集器比应用程序更适合决定内存需求，所以应该利用垃圾收集器在做这些决定方面的帮助，这就是件引用所要做的。如果一个对象惟一剩下的引用是弱引用或软引用，那么该对象是软可及的（softly reachable）。垃圾收集器并不像其收集弱可及的对象一样尽量地收集软可及的对象，相反，它只在真正 “需要” 内存时才收集软可及的对象。软引用对于垃圾收集器来说是这样一种方式，即 “只要内存不太紧张，我就会保留该对象。但是如果内存变得真正紧张了，我就会去收集并处理这个对象。” 垃圾收集器在可以抛出OutOfMemoryError 之前需要清除所有的软引用。通过使用一个软引用来管理高速缓存的缓冲区，可以解决 LeakyChecksum中的问题，如上边代码所示。现在，只要不是特别需要内存，缓冲区就会被保留，但是在需要时，也可被垃圾收集器回收：
——[$]使用软引用修复上边代码段——
public class CachingChecksum
{
private SoftReference<byte[]> bufferRef;
public synchronized int getFileChecksum(String filename)
{
int len = getFileSize(filename);
byte[] byteArray = bufferRef.get();
if( byteArray == null || byteArray.length < len )
{
byteArray = new byte[len];
bufferRef.set(byteArray);
}
readFileContents(filename,byteArray);
}
}
一种廉价缓存：
CachingChecksum使用一个软引用来缓存单个对象，并让 JVM 处理从缓存中取走对象时的细节。类似地，软引用也经常用于 GUI 应用程序中，用于缓存位图图形。是否可使用软引用的关键在于，应用程序是否可从大量缓存的数据恢复。如果需要缓存不止一个对象，您可以使用一个 Map，但是可以选择如何使用软引用。您可以将缓存作为 Map<K, SoftReference<V>> 或SoftReference<Map<K,V>> 管理。后一种选项通常更好一些，因为它给垃圾收集器带来的工作更少，并且允许在特别需要内存时以较少的工作回收整个缓存。弱引用有时会错误地用于取代软引用，用于构建缓存，但是这会导致差的缓存性能。在实践中，弱引用将在对象变得弱可及之后被很快地清除掉——通常是在缓存的对象再次用到之前——因为小的垃圾收集运行得很频繁。对于在性能上非常依赖高速缓存的应用程序来说，软引用是一个不管用的手段，它确实不能取代能够提供灵活终止期、复制和事务型高速缓存的复杂的高速缓存框架。但是作为一种 “廉价（cheap and dirty）” 的高速缓存机制，它对于降低价格是很有吸引力的。正如弱引用一样，软引用也可创建为具有一个相关的引用队列，引用在被垃圾收集器清除时进入队列。引用队列对于软引用来说，没有对弱引用那么有用，但是它们可以用于发出管理警报，说明应用程序开始缺少内存。
2)垃圾回收对引用的处理：
弱引用和软引用都扩展了抽象的 Reference 类虚引用（phantom references），引用对象被垃圾收集器特殊地看待。垃圾收集器在跟踪堆期间遇到一个 Reference 时，不会标记或跟踪该引用对象，而是在已知活跃的 Reference 对象的队列上放置一个 Reference。在跟踪之后，垃圾收集器就识别软可及的对象——这些对象上除了软引用外，没有任何强引用。垃圾收集器然后根据当前收集所回收的内存总量和其他策略考虑因素，判断软引用此时是否需要被清除。将被清除的软引用如果具有相应的引用队列，就会进入队列。其余的软可及对象（没有清除的对象）然后被看作一个根集（root set），堆跟踪继续使用这些新的根，以便通过活跃的软引用而可及的对象能够被标记。处理软引用之后，弱可及对象的集合被识别 —— 这样的对象上不存在强引用或软引用。这些对象被清除和加入队列。所有 Reference 类型在加入队列之前被清除，所以处理事后检查（post-mortem）清除的线程永远不会具有 referent 对象的访问权，而只具有Reference 对象的访问权。因此，当 References 与引用队列一起使用时，通常需要细分适当的引用类型，并将它直接用于您的设计中（与 WeakHashMap 一样，它的 Map.Entry 扩展了 WeakReference）或者存储对需要清除的实体的引用。
3)使用弱引用堵住内存泄漏：
[1]全局Map造成的内存泄漏：
无意识对象保留最常见的原因是使用 Map 将元数据与临时对象（transient object）相关联。假定一个对象具有中等生命周期，比分配它的那个方法调用的生命周期长，但是比应用程序的生命周期短，如客户机的套接字连接。需要将一些元数据与这个套接字关联，如生成连接的用户的标识。在创建 Socket 时是不知道这些信息的，并且不能将数据添加到 Socket 对象上，因为不能控制 Socket 类或者它的子类。这时，典型的方法就是在一个全局 Map 中存储这些信息：
public class SocketManager{
private Map<Socket,User> m = new HashMap<Socket,User>();
public void setUser(Socket s,User u)
{
m.put(s,u);
}
public User getUser(Socket s){
return m.get(s);
}
public void removeUser(Socket s){
m.remove(s);
}
}
SocketManager socketManager;
//...
socketManager.setUser(socket,user);
这种方法的问题是元数据的生命周期需要与套接字的生命周期挂钩，但是除非准确地知道什么时候程序不再需要这个套接字，并记住从 Map 中删除相应的映射，否则，Socket 和 User 对象将会永远留在 Map 中，远远超过响应了请求和关闭套接字的时间。这会阻止 Socket 和User 对象被垃圾收集，即使应用程序不会再使用它们。这些对象留下来不受控制，很容易造成程序在长时间运行后内存爆满。除了最简单的情况，在几乎所有情况下找出什么时候 Socket 不再被程序使用是一件很烦人和容易出错的任务，需要人工对内存进行管理。
[2]弱引用内存泄漏代码：
程序有内存泄漏的第一个迹象通常是它抛出一个 OutOfMemoryError，或者因为频繁的垃圾收集而表现出糟糕的性能。幸运的是，垃圾收集可以提供能够用来诊断内存泄漏的大量信息。如果以 -verbose:gc 或者 -Xloggc 选项调用 JVM，那么每次 GC 运行时在控制台上或者日志文件中会打印出一个诊断信息，包括它所花费的时间、当前堆使用情况以及恢复了多少内存。记录 GC 使用情况并不具有干扰性，因此如果需要分析内存问题或者调优垃圾收集器，在生产环境中默认启用 GC 日志是值得的。有工具可以利用 GC 日志输出并以图形方式将它显示出来，JTune 就是这样的一种工具。观察 GC 之后堆大小的图，可以看到程序内存使用的趋势。对于大多数程序来说，可以将内存使用分为两部分：baseline 使用和 current load 使用。对于服务器应用程序，baseline 使用就是应用程序在没有任何负荷、但是已经准备好接受请求时的内存使用，current load 使用是在处理请求过程中使用的、但是在请求处理完成后会释放的内存。只要负荷大体上是恒定的，应用程序通常会很快达到一个稳定的内存使用水平。如果在应用程序已经完成了其初始化并且负荷没有增加的情况下，内存使用持续增加，那么程序就可能在处理前面的请求时保留了生成的对象。
public class MapLeaker{
public ExecuteService exec = Executors.newFixedThreadPool(5);
public Map<Task,TaskStatus> taskStatus
= Collections.synchronizedMap(new HashMap<Task,TaskStatus>());
private Random random = new Random();
private enum TaskStatus { NOT_STARTED, STARTED, FINISHED };
private class Task implements Runnable{
private int[] numbers = new int[random.nextInt(200)];
public void run()
{
int[] temp = new int[random.nextInt(10000)];
taskStatus.put(this,TaskStatus.STARTED);
doSomework();
taskStatus.put(this,TaskStatus.FINISHED);
}
}
public Task newTask()
{
Task t = new Task();
taskStatus.put(t,TaskStatus.NOT_STARTED);
exec.execute(t);
return t;
}
}
[3]使用弱引用堵住内存泄漏：
SocketManager 的问题是 Socket-User 映射的生命周期应当与 Socket 的生命周期相匹配，但是语言没有提供任何容易的方法实施这项规则。这使得程序不得不使用人工内存管理的老技术。幸运的是，从 JDK 1.2 开始，垃圾收集器提供了一种声明这种对象生命周期依赖性的方法，这样垃圾收集器就可以帮助我们防止这种内存泄漏——利用弱引用。弱引用是对一个对象（称为 referent）的引用的持有者。使用弱引用后，可以维持对 referent 的引用，而不会阻止它被垃圾收集。当垃圾收集器跟踪堆的时候，如果对一个对象的引用只有弱引用，那么这个 referent 就会成为垃圾收集的候选对象，就像没有任何剩余的引用一样，而且所有剩余的弱引用都被清除。（只有弱引用的对象称为弱可及（weakly reachable））WeakReference 的 referent 是在构造时设置的，在没有被清除之前，可以用 get() 获取它的值。如果弱引用被清除了（不管是 referent 已经被垃圾收集了，还是有人调用了 WeakReference.clear()），get() 会返回 null。相应地，在使用其结果之前，应当总是检查get() 是否返回一个非 null 值，因为 referent 最终总是会被垃圾收集的。用一个普通的（强）引用拷贝一个对象引用时，限制 referent 的生命周期至少与被拷贝的引用的生命周期一样长。如果不小心，那么它可能就与程序的生命周期一样——如果将一个对象放入一个全局集合中的话。另一方面，在创建对一个对象的弱引用时，完全没有扩展 referent 的生命周期，只是在对象仍然存活的时候，保持另一种到达它的方法。弱引用对于构造弱集合最有用，如那些在应用程序的其余部分使用对象期间存储关于这些对象的元数据的集合——这就是 SocketManager 类所要做的工作。因为这是弱引用最常见的用法，WeakHashMap 也被添加到 JDK 1.2 的类库中，它对键（而不是对值）使用弱引用。如果在一个普通 HashMap 中用一个对象作为键，那么这个对象在映射从 Map 中删除之前不能被回收，WeakHashMap 使您可以用一个对象作为 Map 键，同时不会阻止这个对象被垃圾收集。下边的代码给出了 WeakHashMap 的 get() 方法的一种可能实现，它展示了弱引用的使用：
public class WeakHashMap<K,V> implements Map<K,V>
{
private static class Entry<K,V> extends WeakReference<K> implements Map.Entry<K,V>
{
private V value;
private final int hash;
private Entry<K,V> next;
// ...
}
public V get(Object key)
{
int hash = getHash(key);
Entry<K,V> e = getChain(hash);
while(e != null)
{
k eKey = e.get();
if( e.hash == hash && (key == eKey || key.equals(eKey)))
return e.value;
e = e.next;
}
return null;
}
}
调用 WeakReference.get() 时，它返回一个对 referent 的强引用（如果它仍然存活的话），因此不需要担心映射在 while 循环体中消失，因为强引用会防止它被垃圾收集。WeakHashMap 的实现展示了弱引用的一种常见用法——一些内部对象扩展 WeakReference。其原因在下面一节讨论引用队列时会得到解释。在向 WeakHashMap 中添加映射时，请记住映射可能会在以后“脱离”，因为键被垃圾收集了。在这种情况下，get() 返回 null，这使得测试 get() 的返回值是否为 null 变得比平时更重要了。
[4]使用WeakHashMap堵住泄漏
在 SocketManager 中防止泄漏很容易，只要用 WeakHashMap 代替 HashMap 就行了，如下边代码所示。（如果 SocketManager 需要线程安全，那么可以用 Collections.synchronizedMap() 包装 WeakHashMap）。当映射的生命周期必须与键的生命周期联系在一起时，可以使用这种方法。不过，应当小心不滥用这种技术，大多数时候还是应当使用普通的 HashMap 作为 Map 的实现。
public class SocketManager{
private Map<Socket,User> m = new WeakHashMap<Socket,User>();
public void setUser(Socket s, User s)
{
m.put(s,u);
}
public User getUser(Socket s)
{
return m.get(s);
}
}
引用队列：
WeakHashMap 用弱引用承载映射键，这使得应用程序不再使用键对象时它们可以被垃圾收集，get() 实现可以根据 WeakReference.get() 是否返回 null 来区分死的映射和活的映射。但是这只是防止 Map 的内存消耗在应用程序的生命周期中不断增加所需要做的工作的一半，还需要做一些工作以便在键对象被收集后从 Map 中删除死项。否则，Map 会充满对应于死键的项。虽然这对于应用程序是不可见的，但是它仍然会造成应用程序耗尽内存，因为即使键被收集了，Map.Entry 和值对象也不会被收集。可以通过周期性地扫描 Map，对每一个弱引用调用 get()，并在 get() 返回 null 时删除那个映射而消除死映射。但是如果 Map 有许多活的项，那么这种方法的效率很低。如果有一种方法可以在弱引用的 referent 被垃圾收集时发出通知就好了，这就是引用队列的作用。引用队列是垃圾收集器向应用程序返回关于对象生命周期的信息的主要方法。弱引用有两个构造函数：一个只取 referent 作为参数，另一个还取引用队列作为参数。如果用关联的引用队列创建弱引用，在 referent 成为 GC 候选对象时，这个引用对象（不是referent）就在引用清除后加入 到引用队列中。之后，应用程序从引用队列提取引用并了解到它的 referent 已被收集，因此可以进行相应的清理活动，如去掉已不在弱集合中的对象的项。（引用队列提供了与 BlockingQueue 同样的出列模式 ——polled、timed blocking 和 untimed blocking。）WeakHashMap 有一个名为 expungeStaleEntries() 的私有方法，大多数 Map 操作中会调用它，它去掉引用队列中所有失效的引用，并删除关联的映射。
4)关于Java中引用思考：
先观察一个列表：
|
级别 |
回收时间 |
用途 |
生存时间 |
|
强引用 |
从来不会被回收 |
对象的一般状态 |
JVM停止运行时终止 |
|
软引用 |
在内存不足时 |
在客户端移除对象引用过后，除非再次激活，否则就放在内存敏感的缓存中 |
内存不足时终止 |
|
弱引用 |
在垃圾回收时，也就是客户端已经移除了强引用，但是这种情况下内存还是客户端引用可达的 |
阻止自动删除不需要用的对象 |
GC运行后终止 |
|
虚引用[幽灵引用] |
对象死亡之前，就是进行finalize()方法调用附近 |
特殊的清除过程 |
不定，当finalize()函数运行过后再回收，有可能之前就已经被回收了。 |
可以这样理解：
SoftReference：假定垃圾回收器确定在某一时间点某个对象是软可到达对象。这时，它可以选择自动清除针对该对象的所有软引用，以及通过强引用链，从其可以到达该对象的针对任何其他软可到达对象的所有软引用。在同一时间或晚些时候，它会将那些已经向引用队列注册的新清除的软引用加入队列。 软可到达对象的所有软引用都要保证在虚拟机抛出 OutOfMemoryError 之前已经被清除。否则，清除软引用的时间或者清除不同对象的一组此类引用的顺序将不受任何约束。然而，虚拟机实现不鼓励清除最近访问或使用过的软引用。 此类的直接实例可用于实现简单缓存；该类或其派生的子类还可用于更大型的数据结构，以实现更复杂的缓存。只要软引用的指示对象是强可到达对象，即正在实际使用的对象，就不会清除软引用。例如，通过保持最近使用的项的强指示对象，并由垃圾回收器决定是否放弃剩余的项，复杂的缓存可以防止放弃最近使用的项。一般来说，WeakReference我们用来防止内存泄漏，保证内存对象被VM回收。
WeakReference：弱引用对象，它们并不禁止其指示对象变得可终结，并被终结，然后被回收。弱引用最常用于实现规范化的映射。假定垃圾回收器确定在某一时间点上某个对象是弱可到达对象。这时，它将自动清除针对此对象的所有弱引用，以及通过强引用链和软引用，可以从其到达该对象的针对任何其他弱可到达对象的所有弱引用。同时它将声明所有以前的弱可到达对象为可终结的。在同一时间或晚些时候，它将那些已经向引用队列注册的新清除的弱引用加入队列。 SoftReference多用作来实现cache机制，保证cache的有效性。
PhantomReference：虚引用对象，在回收器确定其指示对象可另外回收之后，被加入队列。虚引用最常见的用法是以某种可能比使用 Java 终结机制更灵活的方式来指派 pre-mortem 清除操作。如果垃圾回收器确定在某一特定时间点上虚引用的指示对象是虚可到达对象，那么在那时或者在以后的某一时间，它会将该引用加入队列。为了确保可回收的对象仍然保持原状，虚引用的指示对象不能被检索：虚引用的 get 方法总是返回 null。与软引用和弱引用不同，虚引用在加入队列时并没有通过垃圾回收器自动清除。通过虚引用可到达的对象将仍然保持原状，直到所有这类引用都被清除，或者它们都变得不可到达。
以下是不确定概念
【*：Java引用的深入部分一直都是讨论得比较多的话题，上边大部分为摘录整理，这里再谈谈我个人的一些看法。从整个JVM框架结构来看，Java的引用和垃圾回收器形成了针对Java内存堆的一个对象的“闭包管理集”，其中在基本代码里面常用的就是强引用，强引用主要使用目的是就是编程的正常逻辑，这是所有的开发人员最容易理解的，而弱引用和软引用的作用是比较耐人寻味的。按照引用强弱，其排序可以为：强引用——软引用——弱引用——虚引用，为什么这样写呢，实际上针对垃圾回收器而言，强引用是它绝对不会随便去动的区域，因为在内存堆里面的对象，只有当前对象不是强引用的时候，该对象才会进入垃圾回收器的目标区域。
软引用又可以理解为“内存应急引用”，也就是说它和GC是完整地配合操作的，为了防止内存泄漏，当GC在回收过程出现内存不足的时候，软引用会被优先回收，从垃圾回收算法上讲，软引用在设计的时候是很容易被垃圾回收器发现的。为什么软引用是处理告诉缓存的优先选择的，主要有两个原因：第一，它对内存非常敏感，从抽象意义上讲，我们甚至可以任何它和内存的变化紧紧绑定到一起操作的，因为内存一旦不足的时候，它会优先向垃圾回收器报警以提示内存不足；第二，它会尽量保证系统在OutOfMemoryError之前将对象直接设置成为不可达，以保证不会出现内存溢出的情况；所以使用软引用来处理Java引用里面的高速缓存是很不错的选择。其实软引用不仅仅和内存敏感，实际上和垃圾回收器的交互也是敏感的，这点可以这样理解，因为当内存不足的时候，软引用会报警，而这种报警会提示垃圾回收器针对目前的一些内存进行清除操作，而在有软引用存在的内存堆里面，垃圾回收器会第一时间反应，否则就会MemoryOut了。按照我们正常的思维来考虑，垃圾回收器针对我们调用System.gc()的时候，是不会轻易理睬的，因为仅仅是收到了来自强引用层代码的请求，至于它是否回收还得看JVM内部环境的条件是否满足，但是如果是软引用的方式去申请垃圾回收器会优先反应，只是我们在开发过程不能控制软引用对垃圾回收器发送垃圾回收申请，而JVM规范里面也指出了软引用不会轻易发送申请到垃圾回收器。这里还需要解释的一点的是软引用发送申请不是说软引用像我们调用System.gc()这样直接申请垃圾回收，而是说软引用会设置对象引用为null，而垃圾回收器针对该引用的这种做法也会优先响应，我们可以理解为是软引用对象在向垃圾回收器发送申请。反应快并不代表垃圾回收器会实时反应，还是会在寻找软引用引用到的对象的时候遵循一定的回收规则，反应快在这里的解释是相对强引用设置对象为null，当软引用设置对象为null的时候，该对象的被收集的优先级比较高。
弱引用是一种比软引用相对复杂的引用，其实弱引用和软引用都是Java程序可以控制的，也就是说可以通过代码直接使得引用针对弱可及对象以及软可及对象是可引用的，软引用和弱引用引用的对象实际上通过一定的代码操作是可重新激活的，只是一般不会做这样的操作，这样的用法违背了最初的设计。弱引用和软引用在垃圾回收器的目标范围有一点点不同的就是，使用垃圾回收算法是很难找到弱引用的，也就是说弱引用用来监控垃圾回收的整个流程也是一种很好的选择，它不会影响垃圾回收的正常流程，这样就可以规范化整个对象从设置为null了过后的一个生命周期的代码监控。而且因为弱引用是否存在对垃圾回收整个流程都不会造成影响，可以这样认为，垃圾回收器找得到弱引用，该引用的对象就会被回收，如果找不到弱引用，一旦等到GC完成了垃圾回收过后，弱引用引用的对象占用的内存也会自动释放，这就是软引用在垃圾回收过后的自动终止。
最后谈谈虚引用，虚引用应该是JVM里面最厉害的一种引用，它的厉害在于它可以在对象的内存从物理内存中清除掉了过后再引用该对象，也就是说当虚引用引用到对象的时候，这个对象实际已经从物理内存堆中清除掉了，如果我们不用手动对对象死亡或者濒临死亡进行处理的话，JVM会默认调用finalize函数，但是虚引用存在于该函数附近的生命周期内，所以可以手动对对象的这个范围的周期进行监控。它之所以称为“幽灵引用”就是因为该对象的物理内存已经不存在的，我个人觉得JVM保存了一个对象状态的镜像索引，而这个镜像索引里面包含了对象在这个生命周期需要的所有内容，这里的所需要就是这个生命周期内需要的对象数据内容，也就是对象死亡和濒临死亡之前finalize函数附近，至于强引用所需要的其他对象附加内容是不需要在这个镜像里面包含的，所以即使物理内存不存在，还是可以通过虚引用监控到该对象的，只是这种情况是否可以让对象重新激活为强引用我就不敢说了。因为虚引用在引用对象的过程不会去使得这个对象由Dead复活，而且这种对象是可以在回收周期进行回收的。】
0
0
(请您对文章做出评价)
« 上一篇：JVM的运行原理以及JDK 7增加的新特性（二）
» 下一篇：JDK内置工具之一——JMap(java memory map)
posted @ 2013-07-12 20:52 zengdan 阅读(38) 评论(0) 编辑 收藏
发表评论
昵称：
评论内容：
[使用Ctrl+Enter键快速提交]
最新IT新闻:
· 初创公司的创始人该拿多少薪水？
· 欧洲出版巨头承认害怕Google
· 硅谷年轻人已然不爱大公司
· 从现在开始，Square 不再是华尔街的宠儿
· 三星工厂起火导致智能电视报错
» 更多新闻...
最新知识库文章:
· MVC vs. MVP vs. MVVM
· 不是技术牛人，如何拿到国内IT巨头的Offer
· 深入浅出交换类排序算法
· 从Code Review谈如何做技术
· Web开发常见的几个漏洞解决方法
公告
昵称：zengdan
园龄：2年11个月
粉丝：2
关注：0
关注成功
|
|||||||||
|
日 |
一 |
二 |
三 |
四 |
五 |
六 |
|||
|
30 |
31 |
1 |
2 |
3 |
4 |
5 |
|||
|
6 |
7 |
8 |
9 |
10 |
11 |
12 |
|||
|
13 |
14 |
15 |
16 |
17 |
18 |
19 |
|||
|
20 |
21 |
22 |
23 |
24 |
25 |
26 |
|||
|
27 |
28 |
29 |
30 |
1 |
2 |
3 |
|||
|
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|||