Java内存分配
图自慕课网
在java语言中,可作为GCRoot的对象包括以下几种:
- 虚拟机栈中引用的对象,主要是指栈帧中的本地变量
- 本地方法栈中Native方法引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
方法区:
-
又叫
静态区
,跟堆一样,被所有的线程共享。
方法区包含所有的class文件
和static变量/方法
!!! -
方法区中包含的都是在
整个程序中
永远唯一的元素
,如class,static变量。 -
用于存储
已被虚拟机加载的
类信息、常量、静态变量
、即时编译器编译后
的代码/Java Class文件
等数据。 -
与Java堆一样,是各个线程
共享
的内存区域。!!!! -
人们更愿意把这个区域称为“
永久代
”(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)
:首先『标记』出所有需要回收的对象,然后统一『清除』所有被标记的
标记-整理算法(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
的时间更长
。
网友评论