Java平台自动集成线程以及多处理技術内存模型描述了程序中各个变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存中取出变量这样的底层细节对象最终是存储在内存里面的，这点没有错但是编译器、运行库、处理器或者系统缓存可以有特权在变量指萣内存位置存储或者取出变量的值。JMM（Java Memory
Model）允许编译器和缓存以数据在处理器特定的缓存（或寄存器）和主存之间移动的次序拥有重要的特權除非程序员使用 final 或 synchronized明确请求了某些可见性
JSR33的目的是修复JMM的一些缺陷而提出的，其本身的目标有以下几个：
<1> 保留目前JVM的安全保证以进荇类型的安全检查： 提供（ out-of-thin-airsafety） 无中生有安全性，这样“正确同步的”应该被正式 而且直观地定义
<2> 程序员要有信心开发多线程程序当然没囿其他办法使得并发程序变得很容易 开发，但是该规范的发布主要目标是为减轻程序员理解内存模型中的一些细 节负担 提供大范围的流行硬件体系结构上的高性能 JVM实现现在的处理器在它们的 内存模型上有着很大的不同， JMM应该能够适合于实际的尽可能多的体系结构
而不以性能为代价，这也是Java跨平台型设计的基础
<3> 提供一个同步的习惯用法以允许发布一个对象使他不用同步就可见，这种情 况又称为初始化安铨（ initialization safety） 的新的安全保证 对现有代码应该只有最小限度的影
同步：同步就是在发出一个功能调用的时候在没有得到响应之前，该调用就不返回
如：有一个线程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) 可见性、可排序性
synchronized关键字：强制实施一个线 程之间的互斥锁（ 相互排斥） ，该互斥鎖防止每次有多个线程进入一个给定监 控器所保护的同步语句块也就是说在该情况下，执行程序代码所独有的某些 内存是独占模式 其怹的线程是不能针对它执行过程所独占的内存进行访问的，这种情况称为该内存不可见
JVM 在处理该强制实施的时候可以提供一些内存的可見规则，在该规则里面它确保当存在一个同步块时，缓存被更新当输入一个同步块时，缓存失效
JVM 内部提供给定监控器保护的同步块之Φ 一个线程所写入的值对于其余所有的执行由同一个监控器保护的同步块线程来 说是可见的，这就是一个简单的可见性的描述这种机器保证编译器不会把指 令从一个同步块的内部移到外部，虽然有时候它会把指令由外部移动到内部 JMM 在缺省情况下不做这样的保证：只要囿多个线程访问相同变量时必须使 用同步
可见性就是在多核或者多线程运行过程中内存的一种共享模式，在 JMM 模型里面通过并发线程修改變量值的时候，必须将线程变量同步回主存过 后其他线程才可能访问
注：换句话说，内存的可见性使内存资源可以共享当一个线程执荇的时候 它所占有的内存，如果它占有的内存资源是可见的那么这时候其他线程在一 定规则内是可以访问该内存资源的，这种规则是由 JMM 內部定义的这种情 况下内存的该特性称为其可见
可排序性提供了内存内部的访问顺序，在不同的程序针对不同的内存块进 行访问的时候其访问不是无序的
如：有一个内存块， A 和 B 需要访问的时 候 JMM会提供一定的内存分配策略有序地分配它们使用的内存，而在内存的 调用过程也会变得有序地进行内存的折中性质可以简单理解为有序性。而在
JVM中存在一个主存区（Main Memory 或 Java Heap Memory）Java中所有变量都是存在主存中的，对于所囿线程进行共享而每个线程又存在自己的工作内存（Working Memory），工作内存中保
存的是主存中某些变量的拷贝线程对所有变量的操作并非发生茬主存区，而 是发生在工作内存中而线程之间是不能直接相互访问，变量在程序中的传 递是依赖主存来完成的。而在多核处理器下夶部分数据存储在高速缓存中，如果高速缓存不经过内存的时候也是不可见的一种表现
Java 通过 synchronized 和 volatile关键字 提供的内存中模型的可见性保证 程序使用一个特殊的、存储关卡（ memorybarrier） 的指令，来刷新缓存使 缓存无效，刷新硬件的写缓存并且延迟执行的传递过程无疑该机制会对 Java 程序嘚性能产生一定的影响
工作内存储了Java的一 些值，该模型保证了Java里面的属性、方法、字段存在一定的数学特性按照 该特性，该模型存储了對应的一些内容并且针对这些内容进行了一定的序列 化以及存储排序操作，这样使得 Java对象 在工作内存里面被 JVM顺利调用
1> 原子性（Atomicity）： 这一點说明了该模型定义的规则针对原子级别的内容存在独立的影响对 于模型设计最初，这些规则需要说明的仅仅是最简单的读取和存储单え写入的 一些操作这种原子级别的包括——实例、静态变量、数组元素，只是在该 规则中不包括方法中的局部变量
获得或者初始化该值戓 某一些值的时候这些值是由其他线程写入，而且不是从两个或者多个线程产 生的数据在同一时间戳混合写入的时候该字段的原子性茬JVM内部是必须得 到保证的。也就是说JMM在定义JVM原子性的时候只要在该规则不违反的 条件下， JVM本身不去理睬该数据的值是来自于什么线程
2> 鈳见性（Visibility）：在该规则的约束下，定义了一个线程在哪种情况下可以访问另外一个线程 或者影响另外一个线程从JVM的操作上讲包括了从另外一个线程的可见区域 读取相关数据以及将数据写入到另外一个线程内
当一个线程需要修改另外线程的可见单元的时候必须遵循以下原则： 一个写入线程释放的同步锁和紧随其后进行读取的读线程的同步锁是同一个 从本质上讲，释放锁操作强迫它的隶属线程【 释放锁的线程】 从工作内存中的 写入缓存里面刷新（专业上讲这里不应该是刷新可以理解为提供）数据 （ flush操作），然后获取锁操作使得另外一个线程【 获得锁的线程】 直接读取
前一个线程可访问域（也就是可见区域） 的字段的值因为该锁内部提供了一 个同步方法或者同步块，该同步內容具有线程排他性 这样就使得上边两个操 作只能针对单一线程在同步内容内部进行操作，这样就使得所有操作该内容的 单一线程具有該同步内容（加锁的同步方法或者同步块） 内的线程排他性这 种情况的交替也可以理解为具有“短暂记忆效应”
一旦某个字段被申明为 volatile，在任何一个写入线程在工作内存中刷新缓存的 之前需要进行进一步的内存操作 也就是说针对这样的字段进行立即刷新，可 以理解为这種volatile不会出现一般变量的缓存操作而读取线程每次必须根据 前一个线程的可见域里面重新读取该变量的值，而不是直接读取
当某个线程苐一次去访问某个对象的域的时候，它要么初始化该对象的值要 么从其他写入线程可见域里面去读取该对象的值； 这里结合上边理解，茬满足 某种条件下该线程对某对象域的值的读取是直接读取，有些时候却需要重新 读取
注：如果在同一个线程里面通过方法调用去传一個对象的引用是绝对不 会出现上边提及到的可见性问题的 JMM保证所有上边的规定以及关于内存可 见性特性的描述——一个特殊的更新、一個特定字段的修改都是某个线程针对 其他线程的一个“可见性”的概念，最终它发生的场所在内存模型中Java线程和
线程之间至于这个发生時间可以是一个任意长的时间，但是最终会发生也 就是说， Java内存模型中的可见性的特性主要是针对线程和线程之间使用内存 的一种规则囷约定该约定由JMM定义
3> 可排序性（ Ordering）：该规则将会约束任何一个违背了规则调用的线程在操作过程中的一些顺序，排序问题主要围绕了读取、写入和赋值语句有关的序列
注：内存模型本身是存在排序性的
JMM最初设计的时候存在一定的缺陷这种缺陷虽然现有的JVM平台已 经修复，泹是为了读者更加了解JMM的设计思路因此还是提及
1> 不可变对象不是不可变：不可变对象似乎可以改变它们的值（这种对象的不可变指通过使用final关 键字来得到保证） ，（ PublisServiceReminder：让一个对象的所有字段都为 final 并不一定使得这个对象不可变——所有类型还必须是原始类型而不能是对 象的引用而不可变对象被认为不要求同步的。但是因为在将内存写方面的
更改从一个线程传播到另外一个线程的时候存在潜在的延迟，这樣就使得有可 能存在一种竞态条件即允许一个线程首先看到不可变对象的一个值，一段时 间之后看到的是一个不同的值
2> 重新排序的易失性和非易失性存储 ：与 volatile字段的内存操作重新排序有关这个领域中现 有的JMM引起了一些比较混乱的结果。现有的 JMM表明易失性的读和写是直 接囷主存打交道的这样避免了把值存储到寄存器或者绕过处理器特定的缓 存，这使得多个线程一般能看见一个给定变量最新的值可是，結果是这种 volatile
定义并没有最初想象中那样如愿以偿并且导致了 volatile的重大混 乱。为了在缺乏同步的情况下提供较好的性能编译器、运行时和緩存通常是 允许进行内存的重新排序操作的，只要当前执行的线程分辨不出它们的区别 （这就是within-thread as-if-serial semantics[线程内似乎是串行]的解释）但
是，易失性的读和写是完全跨线程安排的编译器或缓存不能在彼此之间重新 排序易失性的读和写。使用易失性变量 initialized担任守卫来表明一套别的操作巳经 完成了这是一个很好的思想，但是不能在 JMM下工作因为旧的 JMM允许 非易失性的写（比如写到 configOptions字段，以及写到由configOptions引用
Map的字段中）与易失性的写一起重新排序因此另外一个线程可能会看到 initialized为 true，但是对于 configOptions字段或它所引用的对象还没有一个一
致的或者说当前的针对内存的视图變量 volatile的旧语义只承诺在读和写的变 量的可见性，而不承诺其他变量虽然这种方法更加有效的实现，但是结果会 和我们设计之初大相径庭
内存管理在Java语言中是JVM自动操作的当JVM发现某些对象不再需 要的时候，就会对该对象占用的内存进行重分配（释放）操作而且使得分配 絀来的内存能够提供给所需要的对象。在一些编程语言里面内存管理是一个 程序的职责，但是书写过C++的程序员很清楚如果该程序需要洎己来书写很 有可能引起很严重的错误或者说不可预料的程序行为，最终大部分开发时间都
花在了调试这种程序以及修复相关错误上一般情况下在Java程序开发过程把 手动内存管理称为显示内存管理，而显示内存管理经常发生的一个情况就是引 用悬挂——也就是说有可能在重噺分配过程释放掉了一个被某个对象引用正在 使用的内存空间释放掉该空间过后，该引用就处于悬挂状态如果这个被悬 挂引用指向的對象试图进行原来对象（因为这个时候该对象有可能已经不存在 了）
进行操作的时候，由于该对象本身的内存空间已经被手动释放掉了這个 结果是不可预知的。显示内存管理另外一个常见的情况是内存泄漏 当某些引 用不再引用该内存对象的时候，而该对象原本占用的内存并没有被释放这种 情况简言为内存泄漏。比如如果针对某个链表进行了内存分配，而因为手动 分配不当仅仅让引用指向了某个元素所处的内存空间，这样就使得其他链表
中的元素不能再被引用而且使得这些元素所处的内存让应用程序处于不可达状 态而且这些对象所占有的内存也不能够被再使用这个时候就发生了内存泄 漏。而这种情况一旦在程序中发生就会一直消耗系统的可用内存直到可用内 存耗尽，而针对计算机而言内存泄漏的严重程度大了会使得本来正常运行的程
序直接因为内存不足而中断并不是Java程序里面出现Exception那么轻量 级
1> 通用介绍：程序运行时有三种内存分配策略： 静态的、栈式的、堆式的
静态存储：是指在编译时就能够确定每个数据目标在运行时的存储涳间 需求，因而在编译时就可以给它们分配固定的内存空间这种分配策略要求程序代码中不允许有可变数据结构的存在，也不允许有嵌套或者递归的结构出 现因为它们都会导致编译程序无法计算准确的存储空间
栈式存储：该分配可成为动态存储分配，是由一个类似于堆棧的运行栈 来实现的和静态存储的分配方式相反，在栈式存储方案中程序对数据区的 需求在编译时是完全未知的，只有到了运行的时候才能知道但是规定在运行 中进入一个程序模块的时候，必须知道该程序模块所需要的数据区的大小才能
分配其内存和我们在数据结構中所熟知的栈一样，栈式存储分配按照先进后 出的原则进行分配
堆式存储：堆式存储分配则专门负责在编译时或运行时模块入口处都无 法确定存储要求的数据结构的内存分配比如可变长度串和对象实例，堆由大 片的可利用块或空闲块组成堆中的内存可以按照任意顺序汾配和释放
2> JVM结构【堆、栈解析】：在 Java虚拟机规范中，一个虚拟机实例的行为主要描述为： 子系统、 内存 区域、 数据类型和指令这些组件茬描述了抽象的JVM内部的一个抽象结构。 与其说这些组成部分的目的是进行JVM内部结构的一种支配更多的是提供一 种严格定义实现的外部行為，该规范定义了这些抽象组成部分以及相互作用的 任何 Java虚拟机
执行所需要的行为下图描述了JVM内部的一个结构，其中 主要包括主要的子系统、内存区域Java虚拟机 有一个类加载器作为JVM的子系统，类加载器针对 Class进行检测 以鉴定完全合格的类接口而JVM内部也有一个执行引擎
当 JVM 运荇一个程序的时候，它的内存需要用来存储很多内容包括字节 码、以及从类文件中提取出来的一些附加信息、以及程序中实例化的对象、方 法参数、返回值、局部变量以及计算的中间结果。 JVM 的内存组织需要在不同 的运行时数据区进行以上的几个操作下边针对上图里面出現的几个运行时数 据区进行详细解析：一些运行时数据区共享了所有应用程序线程和其他特有的
单个线程，每个JVM实例有一个方法区和一个內存堆这些是共同在虚拟机内 运行的线程。在Java程序里面每个新的线程启动过后，它就会被 JVM 在内 部分配自己的PC寄存器[PCregisters]（ 程序计数器器）囷Java堆栈（ Java stacks）若该线程正在执行一个非本地 Java方法，在PC寄存器的值指示下 一条指令执行该线程在 Java内存栈
中保存了非本地Java方法调用状态，其狀 态包括局部变量、被调用的参数、它的返回值、以及中间计算结果而本地方 法调用的状态则是存储在独立的本地方法内存栈里面（nativemethod stacks），这种情况下使得这些本地方法和其他内存运行时数据区的内容尽可 能保证和其他内存运行时数据区独立而且该方法的调用更靠近操作系统，这
些方法执行的字节码有可能根据操作系统环境的不同使得其编译出来的本地字 节码的结构也有一定的差异 JVM中的内存栈是一个栈幀的组合，一个栈帧包 含了某个Java方法调用的状态当某个线程调用方法的时候， JVM就会将一个 新的帧压入到Java内存栈当方法调用完成过后， JVM將会从内存栈中移除该 栈帧 JVM里面不存在一个可以存放中间计算数据结果值的寄存器，其内部指令集使用
Java栈 空间来存储中间计算的数据结果值这种做法的设计是为了保 持 Java虚拟机 的指令集紧凑，使得与寄存器原理能够紧密结合并且进行操作
(1) 方法区（ Method Area） 在 JVM实例中对装载的类型信息是存储在一个逻辑内存方法内存区中， 当 Java虚拟机 加载了一个类型的时候它会跟着这个Class的类型去路径里面查 找对应的Class文件，类加载器读取类文件（线性二进制数据）然后将该文 件传递给Java虚拟机， JVM从二进制数据中提取信息并且将这些信息存储在方
法区而类中声明（靜态）变量就是来自于方法区中存储的信息。在 JVM 里面 用什么样的方式存储该信息是由 JVM 设计的时候决定的例如：当数据进入方 法的时候，哆类文件字节的存储量以 Big-Endian（第一次最重要的字节） 的顺 序存储尽管如此，一个虚拟机可以用任何方式针对这些数据进行存储操作 若它存储在一个 Little-Endian处理器上，设计的时候就有可能将多文件字节的
<1>类型信息：JVM虚拟机 将搜索和使用类型的一些信息也存储在方法区中以方便应用程 序加载读取该数据设计者在设计过程也考虑到要方便 JVM 进行 Java应用程 序的快速执行，而这种取舍主要是为了程序在运行过程中内存不足的凊况能够 通过一定的取舍去弥补内存不足的情况在 JVM内部， 所有的线程共享相同的
方法区因此，访问方法区的数据结构必须是线程安全嘚如果两个线程都试 图去调用去找一个名为 Lava的类，比如Lava还没有被加载 只有一个线程可 以加载该类而另外的线程只能够等待。方法区的夶小在分配过程中是不固定 的随着Java应用程序的运行， JVM可以调整其大小需要注意一点，方法区 的内存不需要是连续的因为方法区内存鈳以分配在内存堆中，即使是虚拟机
JVM实例对象自己所在的内存堆也是可行的而在实现过程是允许程序员自身 来指定方法区的初始化大小嘚
由于 Java 本身的自动内存管理，方法区也会被垃圾回收的 Java 程序 可以通过类扩展动态加载器对象，类可以成为“未引用”向垃圾回收器进行 申请如果一个类是“未引用”的，则该类就可能被卸载 而方法区针对具体的语言特性有几种信息是存储在方法区内的：在 JVM 和 类文件名 嘚内部，类型名一般都是完全限定名 （
java.lang.String）格式在Java源文件里面，完全限定名必须加入包前缀 而不是在开发过程写的简单类名，而在方法仩只要是符合 Java语言规范 的类的完全限定名都可以，而 JVM 可能直接进行解析比如： （ java.lang.String）在JVM内部名称为java/lang/String，这就是我们在异常捕捉 的时候经常看到的
ClassNotFoundException 的异常里面类信息的名称格式 除此之外，还必须为每一种加载过的类型在JVM内进行存储下边的信息 不存储在方法区内
<2>常量池：针對类型加载的类型信息，JVM 将这些存储在常量池里常量池是一个根 据类型定义的常量的有序常量集，包括字面量（ String、 Integer、 Float常量） 以及符号引鼡（类型、字段、方法）整个长量池会被 JVM 的一个索引引用， 如同数组里面的元素集合按照索引访问一样
JVM针对这些常量池里面存储的 信息也是按照索引方式进行。实际上长量池在Java程序的动态链接过程起到了 一个至关重要的作用
<5>类变量：类变量在一个类的多个实例之间共享这些变量直接和类相关，而不是和 类的实例相关 （定义过程简单理解为类里面定义的static类型的变量） ，针 对类变量其逻辑内存部分就昰存储在方法区内的。在 JVM 使用这些类之前 JVM
先要在方法区里面为定义的non-final变量分配内存空间；常量（定义为final） 则在 JVM内部 则不是以同样的方式來进行存储的，尽管针对常量而言一个 final 的类变量是拥有它自己的常量池，作为常量池里面的存储某部分 类常量 是存储在方法区内的，洏其逻辑内存部分则不是按照上边的类变量的方式来进行内
存分配的虽然non-final类变量是作为这些类型声明中存储数据的某一部分， final变量存储為任何使用它类型的一部分的数据格式进行简单存储
<7>方法表：为了提高访问效率必须仔细的设计存储在方法区中的数据信息结构。除 了鉯上讨论的结构 JVM 的实现者还添加一些其他的数据结构，如方法表
(2) 内存栈（Stack）：当一个新线程启动的时候 JVM 会为 Java线程创建每个线程的独立內存 栈，如前所言 Java 的内存栈是由栈帧构成 栈帧本身处于游离状态，在JVM 里面栈帧的操作只有两种： 出栈和入栈。正在被线程执行的方法┅般称为当 前线程方法而该方法的栈帧就称为当前帧，而在该方法内定义的类称为当前
类常量池也称为当前常量池。当执行一个方法洳此的时候 JVM保留当前类 和当前常量池的跟踪，当虚拟机遇到了存储在栈帧中的数据上的操作指令的时 候它就执行当前帧的操作。当一個线程调用某个Java方法时虚拟机创建并 且将一个新帧压入到内存堆栈中，而这个压入到内存栈中的帧成为当前栈帧 当该方法执行的时候， JVM 使用内存栈来存储参数、局部变量、中间计算结果
以及其他相关数据方法在执行过程有可能因为两种方式而结束： 如果一个方 法返回唍成就属于方法执行的正常结束，如果在这个过程抛出异常而结束可 以称为非正常结束，不论是正常结束还是异常结束 JVM都会弹出或者丟弃该 栈帧，则上一帧的方法就成为了当前帧在JVM中， Java线程的栈数据是属于某个线程独有的其他的线程不能够
修改或者通过其他方式来訪问该线程的栈帧，正因为如此这种情况不用担心多 线程同步访问Java的局部变量当一个线程调用某个方法的时候，方法的局部 变量是在方法内部进行的Java栈帧的存储只有当前线程可以访问该局部变量，而其他线程不能随便访问该内存栈里面存储的数据内存栈内的栈帧数据 囷方法区以及内存堆一样， Java栈的栈帧不需要分配在连续的堆栈内或者说
它们可能是在堆，或者两者组合分配实际数据用于表示Java堆栈和棧帧结构 是JVM本身的设计结构决定的，而且在编程过程可以允许程序员指定一个用于 Java堆栈的初始大小以及最大、最小尺寸
内存栈： 这里的内存栈和物理结构内存堆栈有点点区别是内存里面数据存储 的一种抽象数据结构。从操作系统上讲在程序执行过程对内存的使用本身常
鼡的数据结构就是内存堆栈，而这里的内存堆栈指代的就是 JVM 在使用内存过 程整个内存的存储结构 多指内存的物理结构，而Java内存栈不是指玳的一个
物理结构更多的时候指代的是一个抽象结构，就是符合 JVM 语言规范的内存 栈的一个抽象结构 因为物理内存堆栈结构和Java内存栈的抽象模型结构本身
比较相似，所以在学习过程就正常把这两种结构放在一起考虑了而且二 者除了概念上有一点点小的区别，理解成为一種结构对于初学者也未尝不可 所以实际上也可以觉得二者没有太大的本质区别。但是在学习的时候最好分清 楚内存堆栈和Java内存栈的一小點细微的差距前者是物理概念和本身模型， 后者是抽象概念和本身模型的一个共同体而内存堆栈更多的说法可以理解为
一个内存块，洇为内存块可以通过索引和指针进行数据结构的组合 内存栈就 是内存块针对数据结构的一种表示，而内存堆则是内存块的另外一种数据結构 的表示这样理解更容易区分内存栈和内存堆栈（内存块） 的概念
栈帧： 栈帧是内存栈里面的最小单位，指的是内存栈里面每一个最尛内存存储 单元它针对内存栈仅仅做了两个操作： 入栈和出栈，一般情况下：所说的堆
栈帧和栈帧倒是一个概念所以在理解上记得加鉯区分
内存堆： 这里的内存堆和内存栈是相对应的，其实内存堆里面的数据也是存储 在系统内存堆栈里面的只是它使用了另外一种方式來进行堆里面内存的管
理，Java语言本身的内存堆和内存栈而这两个概念 都是抽象的概念模型，而且是相对的
栈帧： 栈帧主要包括三个部分： 局部变量、 操作数栈帧（操作帧） 和帧数 据（数据帧） 本地变量和操作数帧的大小取决于需要，这些大小是在编译时
就决定的并且茬每个方法的类文件数据中进行分配，帧的数据大小则不一 样它虽然也是在编译时就决定的但是它的大小和本身代码实现有关。当JVM 调用┅个Java方法的时候它会检查类的数据来确定在本地变量和操作方法要 求的栈大小，它计算该方法所需要的内存大小然后将这些数据分配恏内存空 间压入到内存堆栈中
栈帧 —— 局部变量： 局部变量是以 Java栈帧 组合成为的一个以零为基的数 组，使用局部变量的时候使用的实际上昰一个包含了0的一个基于索引的数组结 构 int类型、 float、 引用以及返回值都占据了一个数组中的局部变量的条目， 而 byte、 short、 char则在存储到局部变量嘚时候是先转化成为 int再进行操作的则 long 和 double
则是在这样一个数组里面使用了两个元素的空间大小，在 局部变量里面存储基本数据类型的时候使用的就是这样的结构
栈帧——操作帧： 和局部变量一样操作帧也是一组有组织的数组的存储 结构，但是和局部变量不一样的是这个不昰通过数组的索引访问的而是直接 进行的入栈和出栈的操作，当操作指令直接压入了操作栈帧过后从栈帧里面 出来的数据会直接在出棧的时候被读取和使用。除了程序计数器以外操作帧 也是可以直接被指令访问到的， JVM里面没有寄存器处理操作帧的时候Java
虚拟机是基于內存栈的而不是基于寄存器的，因为它在操作过程是直接对内存 栈进行操作而不是针对寄存器进行操作而 JVM内部的指令也可以来源于其他 哋方比如紧接着操作符以及操作数的字节码流或者直接从常量池里面进行操 作。 JVM指令其实真正在操作过程的焦点是集中在内存栈栈帧的操莋帧上的
JVM指令将操作帧作为一个工作空间，有许多指令都是从操作帧里面出栈读取的对指令进行操作过后将操作帧的计算结果重新压叺内存堆栈内。比如 iadd 指令将两个整数压入到操作帧里面然后将两个操作数进行相加，相加的时候 从内存栈里面读取两个操作数的值然後进行运算，最后将运算结果重新存入 到内存堆栈里面
栈帧——数据帧：除了局部变量和操作帧以外 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必须能够通过这个引用快速 从对象堆空间中去拿到该对象能够访问的数据内容也就是说，堆空间内对象 的存储结构必须为外围对象引用提供一种可以访问该对象以及控制该对象的接 ロ使得引用能够顺利地调用该对象以及相关操作因此，针对堆空间的对象 分配的内存中往往也包含了一些指向方法区的指针，因为从整体存储结构上 讲
方法区似乎存储了很多原子级别的内容，包括方法区内最原始最单一的一 些变量：比如类字段、字段数据、类型数据等等
(4)内存栈和内存堆的实现原理探：实际上不论是内存栈结构、方法区还是内存堆结构归根到底使用的是操 作系统的内存，操作系统的內存结构可以理解为内存块常用的抽象方式就是 一个内存堆栈，而JVM在OS上边安装了过后就在启动Java程序的时候按照 配置文件里面的内容向操作系统申请内存空间，该内存空间会按照JVM内部的 方法提供相应的结构调整
内存栈应该是很容易理解的结构实现， 一般情况下内存栈昰保持连续 的，但是不绝对内存栈申请到的地址实际上很多情况下都是连续的，而每个 地址的最小单位是按照计算机位来算的该计算機位里面只有两种状态1和0， 而内存栈的使用过程就是典型的类似 C++里面的普通指针结构的使用过程直 接针对指针进行++或者--操作就修改了该指针针对内存的偏移量，而这些偏移
量就使得该指针可以调用不同的内存栈中的数据至于针对内存栈发送的指令 就是常见的计算机指令，而这些指令就使得该指针针对内存栈的栈帧进行指令 发送比如发送操作指令、变量读取等等，直接就使得内存栈的调用变得更加 简单而且栈帧在接受了该数据过后就知道到底针对栈帧内部的哪一个部分进 行调用，是操作帧、数据帧还是局部变量 内存堆实际上在操作系统里面使用了双向链表的数据结构，双向链表的结
构使得即使内存堆不具有连续性每一个堆空间里面的链表也可以进入下一个 堆空间，而操作系统本身在整理内存堆的时候会做一些简单的操作然后通过 每一个内存堆的双向链表就使得内存堆更加方便。而且堆空间不需偠有序甚 至说有序不影响堆空间的存储结构，因为它归根到底是在内存块上边进行实现 的内存块本身是一个堆栈结构，只是该内存堆棧里面的块如何分配不由 JVM
决定是由操作系统已经最开始分配好了，也就是最小存储单位然后 JVM拿 到从操作系统申请的堆空间过后，先进荇初始化操作然后就可以直接使用 了。
常见的对程序有影响的内存问题主要是两种： 溢出和内存泄漏上边已经 讲过了内存泄漏，其实從内存的结构分析泄漏这种情况很难甚至说不可能发 生在栈空间里面，其主要原因是栈空间本身很难出现悬停的内存因为栈空间 的存儲结构有可能是内存的一个地址数组，所以在访问栈空间的时候使用的都是索引或者下标或者就是最原始的出栈和入栈的操作这些操作使得栈里面很
难出现像堆空间一样的内存悬停（也就是引用悬挂） 问题。堆空间悬停的内存 是因为栈中存放的引用的变化其实引用可以悝解为从栈到堆的一个指针，当 该指针发生变化的时候堆内存碎片就有可能产生，而这种情况下在原始语言 里面就经常发生内存泄漏的凊况因为这些悬停的堆空间在系统里面是不能够 被任何本地指针引用到，就使得这些对象在未被回收的时候脱离了可操作区域 并且占用叻系统资源
栈溢出问题一直都是计算机领域里面的一个安全性问题，这里不做深入讨 论说多了就偏离主题了，而内存泄漏是程序员最嫆易理解的内存问题还有 一个问题来自于我一个黑客朋友就是： 堆溢出现象，这种现象可能更加复杂 其实Java里面的内存结构，最初看来僦是堆和栈的结合实际上可以这样 理解，实际上对象的实际内容才存在对象池里面而有关对象的其他东西有可
能会存储于方法区，而岼时使用的时候的引用是存在内存栈上的这样就更加 容易理解它内部的结构，不仅仅如此有时候还需要考虑到 Java里面的一些字 段和属性箌底是对象域的还是类域的，这个也是一个比较复杂的问题
二者的区别简单总结一下： 管理方式： JVM自己可以针对内存栈进行管理操作，洏且该内存空间的释放是 编译器就可以操作的内容而堆空间在Java中JVM本身执行引擎不会对其进 行释放操作，而是让垃圾回收器进行自动回收 涳间大小： 一般情况下栈空间相对于堆空间而言比较小这是由栈空间里面存 储的数据以及本身需要的数据特性决定的，而堆空间在JVM堆实唎进行分配的
时候一般大小都比较大因为堆空间在一个Java程序中需要存储太多的Java对 象数据 碎片相关： 针对堆空间而言，即使垃圾回收器能夠进行自动堆内存回收但是 堆空间的活动量相对栈空间而言比较大，很有可能存在长期的堆空间分配和释 放操作而且垃圾回收器不是實时的，它有可能使得堆空间的内存碎片主键累 积起来针对栈空间而言，因为它本身就是一个堆栈的数据结构它的操作都
是一一对应嘚，而且每一个最小单位的结构栈帧和堆空间内复杂的内存结构不 一样所以它一般在使用过程很少出现内存碎片。
分配方式： 一般情况丅栈空间有两种分配方式：静态分配和动态分配，静态 分配是本身由编译器分配好了而动态分配可能根据情况有所不同，而堆空间 却昰完全的动态分配的是一个运行时级别的内存分配。而栈空间分配的内存 不需要我们考虑释放问题而堆空间即使在有垃圾回收器的前提下还是要考虑 其释放问题。
效率： 因为内存块本身的排列就是一个典型的堆栈结构所以栈空间的效率自 然比起堆空间要高很多，而且計算机底层内存空间本身就使用了最基础的堆栈 结构使得栈空间和底层结构更加符合它的操作也变得简单就是最简单的两个 指令：入栈囷出栈；栈空间针对堆空间而言的弱点是灵活程度不够，特别是在 动态管理的时候而堆空间最大的优势在于动态分配，因为它在计算机底层实
现可能是一个双向链表结构所以它在管理的时候操作比栈空间复杂很多，自 然它的灵活度就高了但是这样的设计也使得堆空间嘚效率不如栈空间，而且 低很多
Java堆空间是在编写Java程序中被我们使用得最频繁的内存空间平时开 发过程，开发人员一定遇到过OutOfMemoryError这种结果囿可能来源于Java 堆空间的内存泄漏，也可能是因为堆的大小不够而导致的 有时候这些错误是 可以依靠开发人员修复的，但是随着Java程序需要處理越来越多的并发程序 可能有些错误就不是那么容易处理了。有些时候即使Java堆空间没有满也可能
抛出错误这种情况下需要了解的就昰JRE（ JavaRuntimeEnvironment）内部 到底发生了什么。 Java本身的运行宿主环境并不是操作系统而是Java虚拟 机， Java虚拟机本身是用C编写的本机程序自然它会调用到本机資源，最常 见的就是针对本机内存的调用本机内存是可以用于运行时进程的，它和Java 应用程序使用的
Java堆内存不一样每一种虚拟化资源都必须存储在本机内存里面，包括虚拟机本身运行的数据这样也意味着主机的硬件和操作系统在本机内存的限制将直接影响到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） 中的类，也可以使用第 三方库这些类需要存储在内存中以備使用。存储类的方式取决于具体实现 SunJDK 使用永久生成（
permanentgeneration，PermGen）堆区域从最基 本的层面来看，使用更多的类将需要使用更多内存 （这可能意味着您的本机 内存使用量会增加，或者您必须明确地重新设置 PermGen 或共享类缓存等区 域的大小以装入所有类） 。记住不仅您的应用程序需要加载到内存中，框 架、应用服务器、第三方库以及包含类的 Java 运行时也会按需加载并占用空 间 Java
运行时可以卸载类来回收空间，但是呮有在非常严酷的条件下才会这 样做不能卸载单个类，而是卸载类加载器随其加载的所有类都会被卸载。 只有在以下情况下才能卸载類加载器Java 堆不包含对表示该类加载器的 java.lang.ClassLoader 对象的引用。 Java 堆不包含对表示类加载器加载的类的任何 java.lang.Class 对象的引用 在 Java
堆上，该类加载器加载的任何类的所有对象都不再存活（被引用）
(4) Java 运行时为所有 Java 应用程序创建的 3 个默认类加载 器（bootstrap、 extension 和 application ） 都不可能满足这些条件因此，任 何系统類（比如 java.lang.String）或通过应用程序类加载器加载的任何应用程 序类都不能在运行时释放即使类加载器适合进行收集，运行时也只会将收集
类加載器作为GC 周期的一部分一些实现只会在某些 GC 周期中卸载类加 载器，也可能在运行时生成类而不去释放它。许多 JavaEE 应用程序使用 JavaServerPages(JSP) 技术来生荿 Web 页面使用 JSP 会为执行的每个 .jsp 页面生成一个类，并且这些类会在加载它们的类加载器的整个生存期中一直存 在 —— 这个生存期通常是 Web
应用程序的生存期另一种生成类的常见方 法是使用 Java 反射。反射的工作方式因 Java 实现的不同而不同当使用 java.lang.reflectAPI 时， Java 运行时必须将一个反射对象（比洳 java.lang.reflect.Field）的方法连接到被反射到的对象或类这可以通过使用 Java 本机接口（
JavaNativeInterface， JNI） 访问器来完成这种方法需要的 设置很少，但是速度缓慢也可鉯在运行时为您想要反射到的每种对象类型动 态构建一个类。后一种方法在设置上更慢但运行速度更快，非常适合于经常 反射到一个特萣类的应用程序 Java 运行时在最初几次反射到一个类时使用 JNI 方法，但当使用了若干次 JNI 方法之后访问器会膨胀为字节码访问器，
这涉及到构建类并通过新的类加载器进行加载执行多次反射可能导致创建了 许多访问器类和类加载器，保持对反射对象的引用会导致这些类一直存活并 继续占用空间，因为创建字节码访问器非常缓慢所以 Java 运行时可以缓存 这些访问器以备以后使用， 一些应用程序和框架还会缓存反射对象这进一步 增加了它们的本机内存占用
(4) JNI： JNI支持本机代码调用Java方法，反之亦然 Java运行时本身极大依赖于 JNI代码 来实现类库功能，比如文件和网络I/O JNI应用程序可以通过三种方 式增加Java运行时对本机内存的使用： JNI应用程序的本机代码被编译到共享库中，或编译为加载到进程地址涳间中
的可执行文件大型本机应用程序可能仅仅加载就会占用大量进程地址空间 本机代码必须与Java运行时共享地址空间，任何本机代码分配或本机代码执行 的内存映射都会耗用Java运行时内存 某些JNI函数可能在它们的常规操作中使用本机内存 GetTypeArrayElements 和 GetTypeArrayRegion函数可以将Java堆复制到本机内存缓冲區中，提供给
本地代码使用是否复制数据依赖于运行时实现，通过这种方式访问大量 Java 堆数据就可能使用大量的本机内存堆空间
(5) NIO： JDK1.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） 和内部数据结构提供
一些本机内存。尽管每个线程使用的内存量非常小但对于拥有数百个线程的 应用程序来说，线程堆栈的总内存使用量可能非常大如果运行的应用程序的
线程数量比可用于处理它们的处理器数量多，效率通常很低并苴可能导致糟 糕的性能和更高的内存占用
Java运行时善于以不同的方式来处理Java堆空间的耗尽和本机堆空间的 耗尽，但是这两种情形具有类似症狀当Java堆空间耗尽的时候， Java应用程 序很难正常运行因为Java应用程序必须通过分配对象来完成工作，只要Java 堆被填满就会出现糟糕的GC性能，並且抛出OutOfMemoryError相反，一 旦 Java 运行时开始运行并且应用程序处于稳定状态它可以在本机堆完全耗
尽之后继续正常运行， 不一定会发生奇怪的行為因为需要分配本机内存的操 作比需要分配 Java 堆的操作少得多。尽管需要本机内存的操作因 JVM 实现 不同而异但也有一些操作很常见： 启动線程、 加载类以及执行某种类型的网 络和文件 I/O。 本机内存不足行为与 Java 堆内存不足行为也不太一样因为 无法对本机堆分配进行控制，尽管所有 Java 堆分配都在 Java 内存管理系统
控制之下但任何本机代码（无论其位于 JVM、 Java 类库还是应用程序代 码中） 都可能执行本机内存分配，而且会失敗尝试进行分配的代码然后会处 理这种情况，无论设计人员的意图是什么：它可能通过 JNI 接口抛出一个 OutOfMemoryError在屏幕上输出一条消息，发生无提示失败并在稍后再试 一次或者执行其他操作
在Java语言里面， 没有共享内存的概念但是在某些引用中，共享内存却 很受用例如Java语言的汾布式系统，存着大量的Java分布式共享对象很多 时候需要查询这些对象的状态，以查看系统是否运行正常或者了解这些对象目 前的一些统計数据和状态 如果使用的是网络通信的方式，显然会增加应用的 额外开销也增加了不必要的应用编程，如果是共享内存方式则可以矗接通
过共享内存查看到所需要的对象的数据和统计数据，从而减少一些不必要的麻 烦
(1) 共享内存特点： 可以被多个进程打开访问 读写操莋的进程在执行读写操作的时候其他进程不能进行写操作， 多个进程可以交替对某一个共享内存执行写操作 一个进程执行了内存写操作過后，不影响其他进程对该内存的访问同时其他 进程对更新后的内存具有可见性 在进程执行写操作时如果异常退出，对其他进程的写操莋禁止自动解除 相对共享文件数据访问的方便性和效率
(2) 出现情况： 独占的写操作，相应有独占的写操作等待队列独占的写操作本身不會发生数 据的一致性问题； 共享的写操作，相应有共享的写操作等待队列共享的写操作则要注意防止发 生数据的一致性问题； 独占的读操作，相应有共享的读操作等待队列； 共享的读操作相应有共享的读操作等待队列
(3) Java中共享内存的实现： JDK1.4 里面的 MappedByteBuffer 为开发人员在Java中实现共享內存提供 了良好的方法，该缓冲区实际上是一个磁盘文件的内存映象二者的变化会保 持同步，即内存数据发生变化过后会立即反应到磁盤文件中这样会有效地保 证共享内存的实现，将共享文件和磁盘文件简历联系的是文件通道类：
FileChannel该类的加入是JDK为了统一外围设备的访問方法，并且加强了多 线程对同一文件进行存取的安全性这里可以使用它来建立共享内存用，它建 立了共享内存和磁盘文件之间的一个通道打开一个文件可使用 RandomAccessFile类 的 getChannel方法，该方法直接返回一个文件通道该文
件通道由于对应的文件设为随机存取， 一方面可以进行读写两種操作另外一 个方面使用它不会破坏映象文件的内容。这里如果使用 FileOutputStream 和
FileInputStream则不能理想地实现共享内存的要求，因为这两个类同时实现自 甴读写很困难
<1> 永久对象配置：在 java服务器应用中用户可能会在运行过程中配置 一些参数，而这些参数需要永久有效当服务器应用重新启動后，这些配置参
数仍然可以对应用起作用这就可以用到该文 中的共享内存。该共享内存中保 存了服务器的运行参数和一些对象运行特性可以在应用启动时读入以启用以
<2> 查询共享数据：一个应用（例 sys.java）是系统的服务进程，其系 统的运行状态记录在共享内存中其中运行狀态可能是不断变化的。为了随时
了解系统的运行状态启动另一个应用（例 mon.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 提供的HotSpotJVM就支持这一特性
注：Java语言因为提供了垃圾回收器，照理说是不会出现内存泄漏的 Java里面导致内存泄漏的主要原因就昰，先前申请了内存空间而忘记了释放 如果程序中存在对无用对象的引用，这些对象就会驻留在内存中消耗内存因 为无法让GC判断这些對象是否可达。如果存在对象的引用这个对象就被定 义为“有效的活动状态”，同时不会被释放要确定对象所占内存被回收，必须
要確认该对象不再被使用典型的做法就是把对象数据成员设置成为null或者 从集合中移除，当局部变量不需要的情况则不需要显示声明为null
(1) 全局集合： 在大型应用程序中存在各种各样的全局数据仓库是很普遍的比如一个 JNDI树 或者一个Sessiontable（会话表），在这些情况下必须注意管理存储 庫的大小，必须有某种机制从存储库中移除不再需要的数据
解决： [1] 常用的解决方法是周期运作清除作业该作业会验证仓库中的数据然后 清楚一切不需要的数据
[2] 另外一种方式是反向链接计数，集合负责统计集合中每个入口的反向链 接数据这要求反向链接告诉集合合适会退絀入口，当反向链接数目为零的时 候该元素就可以移除了
(2) 缓存： 缓存一种用来快速查找已经执行过的操作结果的数据结构。因此如果┅ 个操作执行需要比较多的资源并会多次被使用，通常做法是把常用的输入数据 的操作结果进行缓存以便在下次调用该操作时使用缓存嘚数据。缓存通常都 是以动态方式实现的,如果缓存设置不正确而大量使用缓存的话则会出现内存溢 出的后果因此需要将所使用的内存容量与检索数据的速度加以平衡
(3) 类加载器： Java类装载器的使用为内存泄漏提供了许多可乘之机。一般来说类装载器 都具有复杂结构因为类装載器不仅仅是只与"常规"对象引用有关，同时也和 对象内部的引用有关比如数据变量， 方法和各种类这意味着只要存在对数 据变量，方法各种类和对象的类装载器，那么类装载器将驻留在JVM中既
然类装载器可以同很多的类关联，同时也可以和静态数据变量关联那么相當 多的内存就可能发生泄漏
Java中的对象引用主要有以下几种类型：
(1) 强可及对象（ strongly reachable）： 可以通过强引用访问的对象，一般来说平时写代码的方式都是使用 的强引用对象，比如下边的代码段：
上边代码部分引用obj这个引用将引用内存堆中的一个对象这种情况 下，只要 obj 的引用存在垃圾回收器就永远不会释放该对象的存储空间。这 种对象我们又成为强引用（ Strong references） 这种强引用方式就是Java语 言的原生的Java引用，几乎每天编程的时候都用到上边代码JVM存储 了一个StringBuilder
类型的对象的强引用在变量builder。强引用和GC的交 互是这样的 如果一个对象通过强引用可达或者通过强引用链可达的话这种对 象就成为强可及对象，这种情况下的对象垃圾回收器不予理睬如果开发 过程不需要垃圾回器回收该对象，就直接將该对象赋为强引用也是普通的编 程方法
(2) 软可及对象（ softly reachable）： 不通过强引用访问的对象，即不是强可及对象但是可以通过软引用访问 的對象就成为软可及对象，软可及对象就需要使用类SoftReference （ java.lang.ref.SoftReference）此种类型的引用主要用于内存比较敏感的高速 缓存，而且此种引用还是具有较强嘚引用功能当内存不够的时候
GC 会回收 这类内存，因此如果内存充足的时候这种引用通常不会被回收的。不仅仅如 此这种引用对象在 JVM 裏面保证在抛 OutOfMemory 异常之前，设置成为 null通俗地讲，这种类型的引用保证在 JVM 内存不足的时候全部被清除但 是有个关键在于： 垃圾收集器在运荇时是否释放软可及对象是不确定的，而且 使用垃圾回收算法并不能保证一次性寻找到所有的软可及对象当垃圾回收器
每次运行的时候嘟可以随意释放不是强可及对象占用的内存，如果垃圾回收器 找到了软可及对象过后可能会进行以下操作： 将 SoftReference对象 的 referent域设置成为null，从而使该对象不再引用heap
销少的对象弱引用也比较有用，和软引用对象不同的是垃圾回收器如果碰 到了弱可及对象，将释放 WeakReference对象的内存但昰垃圾回收器需要运 行很多次才能够找到弱可及对象。弱引用对象在使用的时候可以配合 ReferenceQueue类 使用，如果弱引用被回收 JVM就会把这个弱引鼡加入到相 关的引用队列中去。最简单的弱引用方法如以下代码：
在上边代码里面当使用 weakWidget.get()来获取 classA的时候， 由 于弱引用本身是无法阻止垃圾回收的所以也许会拿到一个 null为返回
注：这里提供一个小技巧，如果我们希望取得某个对象的信息但是又不影响 该对象的垃圾回收过程，就可以使用 WeakReference来记住该对象一般
在开发调试器和优化器的时候使用这个是很好的一个手段
通过 weakWidget.get() 返回的是 null就证明该对 象已经被垃圾回收器回收了，而这种情况下弱引用对象就失去了使用价值 GC 就会定义为需要进行清除工作。这种情况下弱引用无法引用任何对象所以在 JVM里媔就成为了一个死引用，这就是为什么有时候需要通过 ReferenceQueue类来配合使用的原因使用了
ReferenceQueue过后，就使得更加容易监视该引用的对象如果通过┅ ReferenceQueue类来构造一个 弱引用，当弱引用的对象已经被回收的时候系统将自动使用对象引用队列来 代替对象引用，而且可以通过 ReferenceQueue类的运行来决萣是否真正要 从垃圾回收器里面将该死引用（ Dead Reference）清除
// 创建普通引用对象
// 创建一个引用队列
这里提供两个实在的场景来描述弱引用的相关鼡法：
时候，你不得不把对象再从 Hashtable 中移除否则它占用的内存变不会释 放。万一你忘记了那么没有从 Hashtable 中移除的对象也可以算作是内存泄 漏。理想的状况应该是当对象用完时 Hashtable 中的对象会自动被垃圾收集器 回收，不然你就是在做垃圾回收的工作
[2] 你想实现一个图片缓存因为加载图片的开销比较大。你将图片对象的 引用放入这个缓存以便以后能够重新使用这个对象。但是你必须决定缓存中
的哪些图片不再需偠了从而将引用从缓存中移除。不管你使用什么管理缓存 的算法你实际上都在处理垃圾收集的工作，更简单的办法（除非你有特殊的 需求这也应该是最好的办法）是让垃圾收集器来处理，由它来决定回收哪个 对象 当Java回收器遇到了弱引用的时候有可能会执行以下操作： 将WeakReference 对象的 referent域设置成为null，从而使该对象不再引用heap
(4) 清除：当引用对象的referent域设置为null并且引用类在内存堆中引用的对象声 明为可结束的时候，該对象就可以清除清除不做过多的讲述
(5) 虚可及对象（ phantomlyreachable）： 不是强可及对象，也不是软可及对象同样不是弱可及对象，之所以把虚 可及對象放到最后来讲主要也是因为它的特殊性，有时候我们又称之为“幽灵 对象”已经结束的，可以通过虚引用来访问该对象我们使鼡类 虚可及对象的时候， PhantomReference对象就被放在了它的ReferenceQueue
上这就是一个通知，表明PhantomReference引用的对象已经结束可以收集 了，一般情况下我们刚好在对象內存在回收之前采取该行为这种引用不同于 弱引用和软引用，这种方式通过get()获取到的对象总是返回null仅仅当这些 对象在ReferenceQueue队列里面的时候，我们可以知道它所引用的哪些对对象 是死引用（
DeadReference）而这种引用和弱引用的区别在于：
虚引用在堆对象释放之前就添加到了它的ReferenceQueue里面，這种情况使得 可以在堆对象被回收之前采取操作
引用避过了finalize()方法因为对于此方法的执行而言，虚引用真正引用到 的对象是异常对象若茬该方法内要使用对象只能重建。一般情况垃圾回收器 会轮询两次一次标记为finalization，第二次进行真实的回收而往往标记工 作不能实时进行，或者垃圾回收其会等待一个对象去标记 finalization这种情 况很有可能引起MemoryOut，而使用虚引用这种情况就会完全避免
因为虚引 用在引用对象的过程鈈会去使得这个对象由 Dead复活，而且这种对象是可以 在回收周期进行回收的 在JVM内部，虚引用比起使用finalize()方法更加安全一点而且更加有效 而finaliaze()方法回收在虚拟机里面实现起来相对简单，而且也可以处理大部分工作所以我们仍然使用这种方式来进行对象回收的扫尾操作，但是有叻虚引
用过后我们可以选择是否手动操作该对象使得程序更加高效完美
(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 中存储这些信息
程序有内存泄漏的第一个迹象通常是它抛出一个 OutOfMemoryError或 者因为频繁的垃圾收集而表现出糟糕的性能。幸运的是垃圾收集可以提供能 够用来诊断内存泄漏的大量信息。如果以 -verbose:gc 或者 -Xloggc 选项调用 JVM那么每次 GC 运行时在控制台上或者日誌文件中会打印出一个诊断信 息，包括它所花费的时间、当前堆使用情况以及恢复了多少内存记录 GC
使 用情况并不具有干扰性，因此如果需要分析内存问题或者调优垃圾收集器在 生产环境中默认启用 GC 日志是值得的。 有工具可以利用 GC 日志输出并以 图形方式将它显示出来 JTune 就昰这样的一种工具。观察 GC 之后堆大小 的图可以看到程序内存使用的趋势。对于大多数程序来说可以将内存使用 分为两部分： baseline 使用和 current load
使鼡。对于服务器应用程序 baseline 使用就是应用程序在没有任何负荷、但是已经准备好接受请求时的 内存使用， current load 使用是在处理请求过程中使用的、但是在请求处理 完成后会释放的内存只要负荷大体上是恒定的，应用程序通常会很快达到一 个稳定的内存使用水平如果在应用程序巳经完成了其初始化并且负荷没有增
加的情况下，内存使用持续增加那么程序就可能在处理前面的请求时保留了 生成的对象
SocketManager 的问题是 Socket-User 映射的生命周期应当与 Socket 的生 命周期相匹配，但是语言没有提供任何容易的方法实施这项规则这使得程序 不得不使用人工内存管理的老技术。幸运的是从 JDK1.2 开始，垃圾收集器 提供了一种声明这种对象生命周期依赖性的方法这样垃圾收集器就可以帮助 我们防止这种内存泄漏——利用弱引用。弱引用是对一个对象（称为
referent） 的引用的持有者 使用弱引用后，可以维持对 referent 的引用而不 会阻止它被垃圾收集。当垃圾收集器跟踪堆的时候如果对一个对象的引用只 有弱引用，那么这个 referent 就会成为垃圾收集的候选对象就像没有任何剩 余的引用一样，而且所囿剩余的弱引用都被清除 （只有弱引用的对象称为弱 可及（ weaklyreachable）） WeakReference
的 referent 是在构造时设置的，在 没有被清除之前可以用 get() 获取它的值。如果弱引用被清除了（不管是 referent 已经被垃圾收集了还是有人调用了 WeakReference.clear()） ， get() 会返回 null相应地，在使用其结果之前应当总是检查get() 是否返回一个 非 null 值，洇为 referent
最终总是会被垃圾收集的用一个普通的（强）引 用拷贝一个对象引用时，限制 referent 的生命周期至少与被拷贝的引用的生命 周期一样长洳果不小心，那么它可能就与程序的生命周期一样——如果将一 个对象放入一个全局集合中的话另一方面，在创建对一个对象的弱引用時 完全没有扩展 referent 的生命周期，只是在对象仍然存活的时候保持另一种
到达它的方法。弱引用对于构造弱集合最有用如那些在应用程序的其余部分 使用对象期间存储关于这些对象的元数据的集合——这就是 SocketManager 类 所要做的工作。因为这是弱引用最常见的用法 WeakHashMap 也被添加到 JDK1.2 的類库中，它对键（而不是对值）使用弱引用如果在一个普通 HashMap 中用一个对象作为键，那么这个对象在映射从 Map 中删除之前不能
被回收 WeakHashMap 使您鈳以用一个对象作为 Map 键，同时不会阻止这个 对象被垃圾收集下边的代码给出了 WeakHashMap 的 get() 方法的一种可能 实现，它展示了弱引用的使用
调用 WeakReference.get() 时 咜返回一个对 referent 的强引用（ 如果它 仍然存活的话） ，因此不需要担心映射在 while 循环体中消失因为强引用会 防止它被垃圾收集。 WeakHashMap 的实现展示了弱引用的一种常见用法—— 一些内部对象扩展 WeakReference其原因在下面一节讨论引用队列时会得到 解释。在向 WeakHashMap
中添加映射时请记住映射可能会在鉯后“脱离”， 因为键被垃圾收集了在这种情况下， get() 返回 null这使得测试 get() 的返
回值是否为 null 变得比平时更重要了
小心不滥用这种技术，大多數时候还是应当使用普通的 HashMap 作为 Map 的实
引用队列： WeakHashMap 用弱引用承载映射键这使得应用程序不再使用键对象时 它们可以被垃圾收集， get() 实现可以根据 WeakReference.get() 是否返回 null 来区分死的映射和活的映射 但是这只是防止 Map 的内存消耗在应用程序的 生命周期中不断增加所需要做的工作的一半，还需要莋一些工作以便在键对象 被收集后从 Map 中删除死项 否则， Map
会充满对应于死键的项虽然这对 于应用程序是不可见的，但是它仍然会造成应鼡程序耗尽内存因为即使键被
收集了， Map.Entry 和值对象也不会被收集可以通过周期性地扫描 Map，对 每一个弱引用调用 get()并在 get() 返回 null 时删除那个映射而消除死映 射。但是如果 Map 有许多活的项那么这种方法的效率很低。如果有一种方 法可以在弱引用的 referent 被垃圾收集时发出通知就好了这僦是引用队列的
作用。引用队列是垃圾收集器向应用程序返回关于对象生命周期的信息的主要 方法弱引用有两个构造函数：一个只取 referent 作為参数，另一个还取引用 队列作为参数如果用关联的引用队列创建弱引用，在 referent 成为 GC 候选 对象时这个引用对象（不是referent） 就在引用清除后加入 到引用队列中。 之后应用程序从引用队列提取引用并了解到它的 referent
操作中会调用它，它去掉引用队列中所有失效的引用并删除关联 嘚映射
SoftReference：假定垃圾回收器确定在某一时间点某个对象是软可到达对 象。这时它可以选择自动清除针对该对象的所有软引用，以及通过强引用 链从其可以到达该对象的针对任何其他软可到达对象的所有软引用。在同一 时间或晚些时候它会将那些已经向引用队列注册的新清除的软引用加入队 列。 软可到达对象的所有软引用都要保证在虚拟机抛出 OutOfMemoryError
之前已经被清除否则，清除软引用的时间或者清除不同对象嘚一组此类引用 的顺序将不受任何约束 然而，虚拟机实现不鼓励清除最近访问或使用过的软 引用 此类的直接实例可用于实现简单缓存；该类或其派生的子类还可用于更 大型的数据结构，以实现更复杂的缓存只要软引用的指示对象是强可到达对 象，即正在实际使用的对潒就不会清除软引用。例如通过保持最近使用的
项的强指示对象，并由垃圾回收器决定是否放弃剩余的项复杂的缓存可以防 止放弃朂近使用的项。一般来说 WeakReference我们用来防止内存泄漏，保 证内存对象被VM回收
WeakReference：弱引用对象它们并不禁止其指示对象变得可终结，并 被终结然后被回收。弱引用最常用于实现规范化的映射假定垃圾回收器确 定在某一时间点上某个对象是弱可到达对象。这时它将自动清除針对此对象 的所有弱引用，以及通过强引用链和软引用可以从其到达该对象的针对任何 其他弱可到达对象的所有弱引用。同时它将声明所有以前的弱可到达对象为可
终结的在同一时间或晚些时候，它将那些已经向引用队列注册的新清除的弱 引用加入队列 SoftReference多用作来实现cache機制，保证cache的有效 性
PhantomReference：虚引用对象在回收器确定其指示对象可另外回收之 后，被加入队列虚引用最常见的用法是以某种可能比使用 Java 终結机制更 灵活的方式来指派 pre-mortem 清除操作。如果垃圾回收器确定在某一特定时 间点上虚引用的指示对象是虚可到达对象那么在那时或者在以後的某一时 间，它会将该引用加入队列为了确保可回收的对象仍然保持原状，虚引用的
指示对象不能被检索：虚引用的 get 方法总是返回 null與软引用和弱引用不 同，虚引用在加入队列时并没有通过垃圾回收器自动清除通过虚引用可到达 的对象将仍然保持原状，直到所有这类引用都被清除或者它们都变得不可到 达
