java堆栈和垃圾回收
2014-08-09 18:26
387 查看
java JVM管理的内存被分为了很多块。
图片来自http://blog.csdn.net/java2000_wl/article/details/8009362#comments
实际上分的块是不止这些的。
一般开发者所关心的,和我们只需要关心就,就是堆和栈。
堆和栈,顾名思义:采用的数据结构分别是堆和栈。
按照编译原理的观点,程序运行时的内存分配有三种策略,分别是静态的,栈式的,和堆式的.
静态储存分配是指在编译时就能确定每个数据目标在运行时刻的存储空间需求,因而在编译时就可以给他们分配固定的内存空间.这种分配策略要求程序代码中不允许有可变数据结构(比如可变数组)的存在,也不允许有嵌套或者递归的结构出现,因为它们都会导致编译程序无法计算准确的存储空间需求.
工程里定义的静态配置文件,初始化类时类里的静态常量等等,都是静态式储存分配的。这块在上图中没有画出来,在有的版本JVM GC理念中又叫永久区:编译时已知大小。运行过程中大小不会变化。
栈式存储分配也可称为动态存储分配,是由一个类似于堆栈的运行栈来实现的.和静态存储分配相反,在栈式存储方案中,程序对数据区的需求在编译时是完全未知的,只有到运行的时候才能够知道,但是规定在运行中进入一个程序模块时,必须知道该程序模块所需的数据区大小才能够为其分配内存.和我们在数据结构所熟知的栈一样,栈式存储分配按照先进后出的原则进行分配。
类里面定义的,方法体里边定义的比如 int a = 0;或者Object o; 等基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference)类型,这些都是储存局部变量表中的。因此可以看出,栈并不需要多大。java的运行主要是通过多堆和栈的操作。运行时的栈细分为栈帧。该运行帧为当前帧。当前帧执行的时候如果是各类基本数据类型则直接在栈里边取出指进行处理。而如果是reference类型则在对里边寻找相对应的值进行处理。这部分大小已知。
静态存储分配要求在编译时能知道所有变量的存储要求,栈式存储分配要求在过程的入口处必须知道所有的存储要求,而堆式存储分配则专门负责在编译时或运行时模块入口处都无法确定存储要求的数据结构的内存分配,比如可变长度串和对象实例.堆由大片的可利用块或空闲块组成,堆中的内存可以按照任意顺序分配和释放.
堆是gc的主要执行地。而按照gc细分的话堆又细分到了eden,surcicor,old等里边去了。执行频率前往后依次降低。这里边储存的是程序运行中的对象本身。所使用的内存大小未知,且可以随意的分配。它的引用放在栈里边。当引用不再时,发生gc就会将此回收掉。下面以图片加例子对垃圾回收做个讲解(以上黑体字摘抄雨本连接)
使用jconsole工具查看内存分配。
使用代码:
IDE:Eclipse4.3
新生代的GC触法非常的频繁,但并不是每次都将所有内存回收掉。只有当对象的引用被置空之后,对象才会被回收掉。否则,对象将被拷贝至更高一级的垃圾回收区
例如下例:
o置空了,但是l未置空。l仍然在引用这一百个new Object()。
发生在此处的GC将不那么频繁。事实上这块分为很多的小块。他们会在>=2次拷贝之后才会被拷贝至老年区。对比发现年轻代发生GC最频繁的时间段也正是这块发生最频繁的时间段。而这块对空间大小是有严格的要求的,会在一定大小内触法GC而不是等待某个时间点或者某个间隔。(本区域内存占用少了,并不一定是对象被回收了,可能也是相互拷贝到了其他的地方)
老年代的GC相对就不那么频繁了。并且老年代的内存区域相对稳定。
下面再通过一段代码来分析:
很简单的代码,为了OutOfMemeryError。
新生代的大小一直在上升(上面的代码是我手动运行的。我会随时暂停它。这个代码我并没有手动暂停它)
直到手动点击GC触发GC,内存占用直线下降(去哪了?)
图上并不难看出运行过程中的内存占用量。
图片来自http://blog.csdn.net/java2000_wl/article/details/8009362#comments
实际上分的块是不止这些的。
一般开发者所关心的,和我们只需要关心就,就是堆和栈。
堆和栈,顾名思义:采用的数据结构分别是堆和栈。
按照编译原理的观点,程序运行时的内存分配有三种策略,分别是静态的,栈式的,和堆式的.
静态储存分配是指在编译时就能确定每个数据目标在运行时刻的存储空间需求,因而在编译时就可以给他们分配固定的内存空间.这种分配策略要求程序代码中不允许有可变数据结构(比如可变数组)的存在,也不允许有嵌套或者递归的结构出现,因为它们都会导致编译程序无法计算准确的存储空间需求.
工程里定义的静态配置文件,初始化类时类里的静态常量等等,都是静态式储存分配的。这块在上图中没有画出来,在有的版本JVM GC理念中又叫永久区:编译时已知大小。运行过程中大小不会变化。
栈式存储分配也可称为动态存储分配,是由一个类似于堆栈的运行栈来实现的.和静态存储分配相反,在栈式存储方案中,程序对数据区的需求在编译时是完全未知的,只有到运行的时候才能够知道,但是规定在运行中进入一个程序模块时,必须知道该程序模块所需的数据区大小才能够为其分配内存.和我们在数据结构所熟知的栈一样,栈式存储分配按照先进后出的原则进行分配。
类里面定义的,方法体里边定义的比如 int a = 0;或者Object o; 等基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference)类型,这些都是储存局部变量表中的。因此可以看出,栈并不需要多大。java的运行主要是通过多堆和栈的操作。运行时的栈细分为栈帧。该运行帧为当前帧。当前帧执行的时候如果是各类基本数据类型则直接在栈里边取出指进行处理。而如果是reference类型则在对里边寻找相对应的值进行处理。这部分大小已知。
静态存储分配要求在编译时能知道所有变量的存储要求,栈式存储分配要求在过程的入口处必须知道所有的存储要求,而堆式存储分配则专门负责在编译时或运行时模块入口处都无法确定存储要求的数据结构的内存分配,比如可变长度串和对象实例.堆由大片的可利用块或空闲块组成,堆中的内存可以按照任意顺序分配和释放.
堆是gc的主要执行地。而按照gc细分的话堆又细分到了eden,surcicor,old等里边去了。执行频率前往后依次降低。这里边储存的是程序运行中的对象本身。所使用的内存大小未知,且可以随意的分配。它的引用放在栈里边。当引用不再时,发生gc就会将此回收掉。下面以图片加例子对垃圾回收做个讲解(以上黑体字摘抄雨本连接)
使用jconsole工具查看内存分配。
使用代码:
package aboutThread; import java.util.LinkedList; import java.util.List; public class MeneryModel { int plus = 0; private List<Integer> list ; private InnerThread t1; private InnerThread t2; public static void main(String[] args) { MeneryModel mm = new MeneryModel(); mm.go(); } class InnerThread extends Thread { int id; public InnerThread(int id) { this.id = id; } public void run() { while (true) { synchronized (list) { System.out.println("arrive : " + id); list.add(plus +++ id); list.add(plus +++ id); list.remove(0); if (list.size() >= 10) { System.out.println(list); break; } } try { sleep(10); } catch (InterruptedException e) { e.printStackTrace(); } } } } public void go() { list = new LinkedList<>(); t1 = new InnerThread(1000); t2 = new InnerThread(2000); t1.start(); t2.start(); } }
IDE:Eclipse4.3
新生代的GC触法非常的频繁,但并不是每次都将所有内存回收掉。只有当对象的引用被置空之后,对象才会被回收掉。否则,对象将被拷贝至更高一级的垃圾回收区
例如下例:
List<Object> l = new LinkedList<>(); for (int i = 0 ; i < 100 ; i ++) { Object o = new Object(); l.add(o); o = null; }
o置空了,但是l未置空。l仍然在引用这一百个new Object()。
发生在此处的GC将不那么频繁。事实上这块分为很多的小块。他们会在>=2次拷贝之后才会被拷贝至老年区。对比发现年轻代发生GC最频繁的时间段也正是这块发生最频繁的时间段。而这块对空间大小是有严格的要求的,会在一定大小内触法GC而不是等待某个时间点或者某个间隔。(本区域内存占用少了,并不一定是对象被回收了,可能也是相互拷贝到了其他的地方)
老年代的GC相对就不那么频繁了。并且老年代的内存区域相对稳定。
下面再通过一段代码来分析:
很简单的代码,为了OutOfMemeryError。
新生代的大小一直在上升(上面的代码是我手动运行的。我会随时暂停它。这个代码我并没有手动暂停它)
直到手动点击GC触发GC,内存占用直线下降(去哪了?)
图上并不难看出运行过程中的内存占用量。
相关文章推荐
- Java基础必备 -- 堆栈、引用传值、垃圾回收等
- JAVA的堆栈和内存、垃圾回收解说
- JAVA的堆栈和内存、垃圾回收解说
- Java杂谈之垃圾回收和clone以及堆栈的存储
- java堆栈和垃圾回收
- java 数组(堆栈内存、默认值与垃圾回收)
- JVM内存管理 垃圾回收 及java的堆栈 待补充
- Java的垃圾回收机制详解和调优
- java垃圾回收之Map【原创】
- Java的垃圾回收(Garbage Collection)机制
- Java堆的管理--垃圾回收
- Java的垃圾回收机制研究
- Java堆的管理--垃圾回收
- Java与C#的垃圾回收机制
- 【转载】Java堆的管理--垃圾回收
- Java的垃圾回收(Garbage Collection)机制
- 深入浅出Java堆的管理--垃圾回收
- JVM详解之Java垃圾回收机制详解和调优
- 深入浅出Java堆的管理--垃圾回收
- Java堆的管理--垃圾回收