Java内存分配
在java语言中，可作为GCRoot的对象包括以下几种：
- 虚拟机栈中引用的对象，主要是指栈帧中的本地变量
- 本地方法栈中Native方法引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- GCRoot
- JVM判断引用失效，可达性分析是否可以解决循环引用
- 要点提炼| 理解JVM之GC&内存分配
方法区：
- **又叫
静态区，与Java堆一样，是所有线程共享的内存区域。！！！！
方法区包含所有的class文件和static变量/方法！！！**
- 方法区中包含的都是在
整个程序中永远唯一的元素，如class，static变量。 - **用于存储
已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码/Java Class文件等数据。**
- **人们更愿意把这个区域称为“
永久代”（Permanent Generation），
在发布的JDK1.7的HotSpot中，已经把原本放在永久代的字符串常量池移出。
它还有个别名叫做Non-Heap（非堆）。**
- **除了和
Java堆一样，
不需要连续的内存和
可以选择固定大小或可扩展外，
还可选择不实现GC。**
- **在
Java虚拟机规范中，
当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。**
栈
- **每个线程包含一个
栈区，栈中只保存
基础数据类型的对象引用及其对应的值以及基础数据的引用
（Java语言提供了八种基本数据类型：
六种数字类型（四个整数型long、int、short、byte，两个浮点型float、double），
一种字符类型String，还有一种布尔型）**
- **每个栈中的数据(
基础数据类型和对象引用)都是私有的，其他栈不能访问。**
- **栈分为3个部分：
基本类型变量区、执行环境上下文、操作指令区(存放操作指令)。**
虚拟机栈
- **每个方法在执行的同时都会创建一个
栈帧，
用于存储局部变量表、操作数栈、动态链接、方法出口等信息。**
- **每一个
方法从调用直至执行完成的过程，
就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。**
**局部变量表存放了编译期可知的
各种基本数据类型、对象引用类型和returnAddress类型，
它所需的内存空间在编译期间完成分配。**
- 是
线程私有的内存，与线程生命周期相同。！！！！ - **一般把Java内存区分为
堆内存（Heap）和栈内存（Stack），
其中『栈』指的是虚拟机栈，『堆』指的是Java堆。**
在
Java虚拟机规范中，对这个区域规定了两种异常状况：- **如果
线程请求的栈深度大于虚拟机所允许的深度，
- **如果
将抛出StackOverflowError异常；**
- **如果虚拟机栈`可动态扩展`且`扩展时`无法申请到`足够的内存`，将抛出OutOfMemoryError异常。**
本地方法栈
- 存储局部变量表、操作数栈等；
- **是虚拟机使用到的
Native方法服务。
在虚拟机规范中，对这个区域无强制规定，由具体的虚拟机自由实现。
与虚拟机栈一样，
本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。**
- **
虚拟机栈是为Java方法服务的；
本地方法栈是为Native方法服务的；**
当然还要注意String的特殊性
- 一个例子：
- **还有一例：**
堆
- **存储的全部是对象，
每个对象都包含一个与之对应的class的信息。
(class的目的是得到操作指令)**
- jvm只有一个堆区(heap)被所有线程共享，堆中不存放基本类型和对象引用，只存放
对象本身 - **被所有线程共享的一块内存区域，在虚拟机启动时创建；
包含一切new出来的对象；**
- **每一个对象的
实际分配内存都是在堆上进行分配的；
用于存放几乎所有的对象实例和数组。**
**在Java堆中，
可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB），
但无论哪个区域，存储的都仍然是对象实例，
进一步划分的目的是
为了更好地回收内存，
或者更快地分配内存。**
- **在
虚拟机栈中，分配的只是引用，
虚拟机栈当中的引用，会指向在堆中真正创建的对象；**
- **是
GC主要作用、管理的区域，因为所占内存最大，最有可能产生垃圾，也被称做“GC堆”；
经常说的内存泄漏也是发生在此区域；**
- 是Java虚拟机所管理的
内存中最大的一块。 - 可处于
物理上不连续的内存空间中，只要逻辑上是连续的即可。 - **在
Java虚拟机规范中，
如果在堆中没有内存完成实例分配，且堆也无法再扩展时，
将会抛出OutOfMemoryError异常。**
程序计数器（Program Counter Register）
是
当前线程所执行的字节码的行号指示器。- **如果
线程正在执行的是一个Java方法，
- **如果
那么计数器记录的是正在执行的虚拟机字节码指令的地址；**
- **如果`线程`正在执行的是一个`Native方法`，那么计数器的值则为空。**
**注意：！！！！！！！
计数器的值代表着下一条需要执行的字节码指令，！！！
字节码解释器工作时，
就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，！！！！
分支、循环、跳转、异常处理、线程恢复等基础功能
都需要依赖这个计数器来完成。**
- **为了
线程切换后能恢复到正确的执行位置，
每条线程都需要有一个独立的程序计数器，
各条线程之间计数器互不影响，独立存储，
因此它是线程私有的内存。！！！！！！！**
- **在
Java虚拟机规范中，
是唯一一个没有规定任何OutOfMemoryError情况的区域。**
JVM垃圾回收算法
回收算法有以下四种：
分代收集算法（1）：是当前商业虚拟机都采用的一种算法，根据对象存活周期的不同，将Java堆划分为新生代和老年代，并根据各个年代的特点采用最适当的收集算法。
新生代：大批对象死去，只有少量存活。使用『复制算法』，只需复制少量存活对象即可。
复制算法（2）：把可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用尽后，把还
存活着的对象『复制』到另外一块上面，
再将这一块内存空间一次清理掉。- **```老年代```**：对象存活率高。使用『标记—清理算法』或者『标记—整理算法』，只需标记较少的回收对象即可。 - **```标记-清除算法（3）```**：首先『标记』出所有需要回收的对象，然后统一『清除』所有被标记的<br> - **```标记-整理算法（4）```**：首先『标记』出所有需要回收的对象，然后进行『整理』，使得存活的对象都向一端移动，最后直接清理掉端边界以外的内存。
- **
标记-清除算法效率其实不高，
它需要从头到尾对内存中的每一个对象做标记；
并且会产生大量的不连续的内存碎片；
如上的第四行内存，可能两块蓝色之间的那一块内存都是用不了的，
只能用后面的三块来分配，
即前面出现了内存空洞；**
- **
复制算法的相较于标记-清除算法，效率是高一点的，
每一次只需对二分之一的内存进行标记，
同时避免内存空洞；
但是浪费了一半空间，代价大；**
标记-整理算法
避免标记-清理导致的内存碎片（及内存空洞）；
避免复制算法的空间浪费；
Android内存管理机制
内存（按需）弹性分配
**分配值与最大值受具体设备影响；不同配置的手机，其单个APP可以使用的内存是不同的；**
比如多者有单个APP可以使用512M的内存的，少者128M甚至更甚；
OOM场景：
OOM有时候是APP自己的原因，有时候也可能是整个系统的原因；
- APP使用内存真正不足，超限：
比如某一个手机，其单个APP 最大可以使用的内存 是512M，
假设有一个APP 已经使用了510M了，这时候如果还要再申请一个3M的空间，
这时候内存是真正不足了，超过了最大限制，要抛出OOM内存溢出异常；
- 系统可用内存不足：
**就是，
即使 APP使用的内存 没有超过 系统规定的最大限制，
但是整个系统的内存已经不够用了，AMS回收了别的进程 也不够分了，
没办法多分配给APP内存了，
这时候也会抛出OOM 内存溢出异常；**
如某一个手机，其单个APP 最大可以使用的内存 是512M，
一个APP只用了200M，再要申请一个几十M的内存时，
系统也抛出OOM内存溢出异常；
Dalvik 和 ART的区别（关注点：程序运行时、GC算法）
参考链接：
Android 4.4之前，Android系统一直都是在Dalvik 虚拟机上的，
从Android 4.4开始开始引入ART，到5.0已经成为默认选择。
- **
Dalvik仅固定一种回收算法，！！！！
手机出厂之前已经设定好了，运行期间无法改变；
另外，
应用程序每次运行时，！！！！都需要将程序内的代码即使转变为机器码才能运行，这无形中多附加了一道手续，**
这就造成了耗电相对较快、占用内存大、即使是旗舰机用久了也会卡顿严重的现象。
- ART，Android Runtime 的简称。
优点：
- **通过在安装应用程序时，自动对程序进行代码预读取编译，
让程序
直接编译成机器语言，运行时直接运行 无需再做转化，！！！！
免去了Dalvik模式运行时要时时转换代码，**
- 实现高效率、省电、占用更低的系统内存、手机运行流畅。
缺点：
- 占用略高一些的存储空间；
- 安装程序时要相比普通 Dalvik 模式要长一些时间来实现预编译；
- **Android5.0之后都是默认使用
ART虚拟机，
其回收算法，是可以在APP运行期间进行选择的，！！！！
可以在不同的情况下，选择合适的垃圾回收算法；
如果，
APP正跑在前台，和用户正在交互，
此时此景，自然响应速度最重要！
对于用户来说，需要APP能够及时响应，
此时应该选择一种简单的算法——标记-清除算法；
如果，
APP切到了后台，
则可以选择标记-整理算法，作为补充；
（也就是说，ART 相对于 Dalvik 而言，
具备内存整理能力，减少内存空洞）**
Low Memory Killer 机制
机制目的：保证大多数情况下，不会出现内存不足的情境；
- 针对所有进程；
- 当手机内存不足，Low Memory Killer 机制就会 针对所有进程 进行回收；
- **
进程分类：
Android系统将进程分为以下几类：
（进程优秀级从前往后，从高到低）
前台进程，可见进程，服务进程，后台进程，空进程；
（Foreground进程、Visible进程、Service进程、Background进程、Empty进程）**
**如果用户按Home键返回桌面，那么该app成为Background进程；
如果按Back返回，则成为Empty进程。**
- **RAM（内存）不足时，
Low Memory Killer 会找优先级低的进程，优先进行回收，
杀死优先级较低的进程，让高优先级进程获取更多内存；
同时还会考虑一个因素——回收收益，
即 回收 某一个进程 能 收回 多大的内存；**
- **
ActivityManagerService直接管理所有进程的内存资源分配。
所有进程要申请或释放内存都需要通过ActivityManagerService对象。**
- **垃圾回收不定期执行。
当内存不够时就会遍历heap空间，把垃圾对象删除。**
堆内存越大，则GC的时间更长。
