Java虚拟机内存分配

最新推荐文章于 2021-02-24 13:09:23 发布
最新推荐文章于 2021-02-24 13:09:23 发布
阅读量346 收藏 1
点赞数
分类专栏： java

简单来说，对象内存分配主要是在堆中分配。但是分配的规则并不是固定的，取决于使用的收集器组合以及JVM内存相关参数的设定

以下介绍几条基本规则（使用的ParNew+Serial Old收集器组合）：

一，对象优先在新生代Eden区分配

[java]  view plain  copy
  1. //-XX:+UseParNewGC -Xms20m -Xmx20m -Xmn10m -XX:+PrintHeapAtGC -XX:+PrintGCDetails  
  2. public class test {  
  3.     static int mb = 1024*1024;  
  4.       
  5.     public static void main(String[] args) {  
  6.         byte[] b1 = new byte[2*mb];  
  7.         System.out.println("b1 over");  
  8.         byte[] b2 = new byte[2*mb];  
  9.         System.out.println("b2 over");  
  10.         byte[] b3 = new byte[2*mb];  
  11.         System.out.println("b3 over");//GC  
  12.         byte[] b4 = new byte[4*mb];  
  13.         System.out.println("b4 over");  
  14.     }  
  15. }  

堆内存大小为20M，不可自动扩展，新生代内存大小为10M，根据默认值，Eden区：Survivor区为8:1，Eden区大小应为：10M*8/10=8129KB，Survivor区大小应为1024KB，新生代总可用内存应为9216KB

当b3分配完成后，新生代将使用6M内存（6144KB，b1+b2+b3），同时申请b4的4M=4096KB内存，此时新生代的可用内存为9216-6144=3072KB，不足以分配b4的空间，则触发一次Minor GC回收新生代内存空间，由于b1、b2以及b3都为存活状态，并且剩余的一个Survivor区无法装下b1、b2和b3，则新生代会租借老年代的区域，并将b1、b2和b3移动至租借区域，然后新生代完成Minor GC。由于此时新生代已经没有对象存放其中，剩余大量内存，则b4将在新生代中分配

[plain]  view plain  copy
  1. b1 over  
  2. b2 over  
  3. b3 over  
  4. {Heap before GC invocations=0 (full 0):  
  5.  par new generation   total 9216K, used 6487K [0x03b30000, 0x04530000, 0x04530000)//b1+b2+b3，占6M  
  6.   eden space 8192K,  79% used [0x03b30000, 0x04185f60, 0x04330000)  
  7.   from space 1024K,   0% used [0x04330000, 0x04330000, 0x04430000)  
  8.   to   space 1024K,   0% used [0x04430000, 0x04430000, 0x04530000)  
  9.  tenured generation   total 10240K, used 0K [0x04530000, 0x04f30000, 0x04f30000)//老年代为空  
  10.    the space 10240K,   0% used [0x04530000, 0x04530000, 0x04530200, 0x04f30000)  
  11.  compacting perm gen  total 12288K, used 2105K [0x04f30000, 0x05b30000, 0x08f30000)  
  12.    the space 12288K,  17% used [0x04f30000, 0x0513e478, 0x0513e600, 0x05b30000)  
  13. No shared spaces configured.  
  14. [GC [ParNew: 6487K->150K(9216K), 0.0092952 secs] 6487K->6294K(19456K), 0.0093314 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]//对象仍处于存活状态，新生代无足够的空间完成Minor GC，只能租借老年代的空间，将b1、b2和b3移动至老年代   
  15. Heap after GC invocations=1 (full 0):  
  16.  par new generation   total 9216K, used 150K [0x03b30000, 0x04530000, 0x04530000)//新生代几乎被清空  
  17.   eden space 8192K,   0% used [0x03b30000, 0x03b30000, 0x04330000)  
  18.   from space 1024K,  14% used [0x04430000, 0x04455a10, 0x04530000)  
  19.   to   space 1024K,   0% used [0x04330000, 0x04330000, 0x04430000)  
  20.  tenured generation   total 10240K, used 6144K [0x04530000, 0x04f30000, 0x04f30000)//b1+b2+b3  
  21.    the space 10240K,  60% used [0x04530000, 0x04b30030, 0x04b30200, 0x04f30000)  
  22.  compacting perm gen  total 12288K, used 2105K [0x04f30000, 0x05b30000, 0x08f30000)  
  23.    the space 12288K,  17% used [0x04f30000, 0x0513e478, 0x0513e600, 0x05b30000)  
  24. No shared spaces configured.  
  25. }  
  26. b4 over  
  27. Heap  
  28.  par new generation   total 9216K, used 4410K [0x03b30000, 0x04530000, 0x04530000)//b4  
  29.   eden space 8192K,  54% used [0x03b30000, 0x03f82008, 0x04330000)  
  30.   from space 1024K,  14% used [0x04430000, 0x04455a10, 0x04530000)  
  31.   to   space 1024K,   0% used [0x04330000, 0x04330000, 0x04430000)  
  32.  tenured generation   total 10240K, used 6144K [0x04530000, 0x04f30000, 0x04f30000)//b1+b2+b3  
  33.    the space 10240K,  60% used [0x04530000, 0x04b30030, 0x04b30200, 0x04f30000)  
  34.  compacting perm gen  total 12288K, used 2116K [0x04f30000, 0x05b30000, 0x08f30000)  
  35.    the space 12288K,  17% used [0x04f30000, 0x051413c8, 0x05141400, 0x05b30000)  
  36. No shared spaces configured.  

二，大对象直接进入老年代

为了避免内存回收时大对象在Eden区和2个Survivor区之间的拷贝（ParNew收集器使用复制算法），同时为了避免为了提供足够的内存空间而提前触发的GC，虚拟机提供了-XX:PretenureSizeThreshold（该设置只对Serial和ParNew收集器生效）参数，大于该参数设置值的对象将直接在老年代分配

[java]  view plain  copy
  1. //-XX:+UseParNewGC -Xms20m -Xmx20m -Xmn10m -XX:+PrintHeapAtGC -XX:+PrintGCDetails   
  2. //-XX:PretenureSizeThreshold=2097152  
  3. public class test {  
  4.     static int mb = 1024*1024;  
  5.       
  6.     public static void main(String[] args) {  
  7.         byte[] b1 = new byte[3*mb];  
  8.         System.out.println("b1 over");  
  9.     }  
  10. }  

由于设置超过2M（2*1024*1024=2097152B）的对象直接在老年代分配，故b1将分配在老年代上

[plain]  view plain  copy
  1. b1 over  
  2. Heap  
  3.  par new generation   total 9216K, used 507K [0x03b50000, 0x04550000, 0x04550000)//新生代几乎为空  
  4.   eden space 8192K,   6% used [0x03b50000, 0x03bcef00, 0x04350000)  
  5.   from space 1024K,   0% used [0x04350000, 0x04350000, 0x04450000)  
  6.   to   space 1024K,   0% used [0x04450000, 0x04450000, 0x04550000)  
  7.  tenured generation   total 10240K, used 3072K [0x04550000, 0x04f50000, 0x04f50000)//老年代使用了3*1024K内存  
  8.    the space 10240K,  30% used [0x04550000, 0x04850010, 0x04850200, 0x04f50000)  
  9.  compacting perm gen  total 12288K, used 2110K [0x04f50000, 0x05b50000, 0x08f50000)  
  10.    the space 12288K,  17% used [0x04f50000, 0x0515f8c8, 0x0515fa00, 0x05b50000)  
  11. No shared spaces configured.  

三，长期存活对象将进入老年代
由于虚拟机垃圾收集是基于“分代算法”的，故虚拟机必须能够识别哪些对象存放在新生代，哪些对象应该存放在老年代

虚拟机设计了一个对象年龄计数器，如果对象在Eden区出生并且经过第一次Minor GC后依然存活，并且可以被Survivor区容纳，就会被复制至Survivor区并将对象年龄设置为1。以后对象每熬过一次Minor GC，对象年龄便+1。当对象年龄超过对象晋升老年代的年龄阀值（该阀值默认为15）时，便会晋升至老年代，何时晋升，我们接下来研究

虚拟机提供了-XX：MaxTenuringThreshold参数设置晋升阀值

[java]  view plain  copy
  1. //-XX:+UseParNewGC -Xms20m -Xmx20m -Xmn10m -XX:+PrintHeapAtGC -XX:+PrintGCDetails   
  2. //-XX:MaxTenuringThreshold=1  
  3. public class test {  
  4.     static int mb = 1024*1024;  
  5.       
  6.     public static void main(String[] args) {  
  7.         System.out.println("step 1");  
  8.         byte[] b1 = new byte[1*mb/4];  
  9.         System.out.println("step 2");  
  10.         byte[] b2 = new byte[4*mb];  
  11.         System.out.println("step 3");  
  12.         byte[] b3 = new byte[4*mb];//GC  
  13.         System.out.println("step 4");  
  14.         b3 = null;  
  15.         System.out.println("step 5");  
  16.         b3 = new byte[4*mb];//GC  
  17.     }  
  18. }  

b1、b2正常分配。在step3，新生代将没有足够的内存分配b3所需的4M空间，故引发一次Minor GC。b1只有256KB，可以放置在Survivor区中，故复制b1到Survivor区中，b2为4M，无法放置到Survivor区中，故租借老年代4M内存放置b2，回收新生代内存空间，b1经历了一次Minor GC后依然存活，故年龄变为1。

在step4，分配给b3对象的内存空间依然被占用，只是将b3对象的引用置为空，由于不涉及到内存分配，故而不涉及到GC，因此对象的年龄也不会发生变化

在step5，重新给b3对象分配4M空间，由于新生代没有足够内存，故引发Minor GC，step3分配给b3的4M内存空间由于不再与存活对象相关联，将被回收，同时，由于b1的年龄到达对象晋升老年代的年龄设置，b1将被移动至老年代

[plain]  view plain  copy
  1. step 1  
  2. step 2  
  3. step 3  
  4. {Heap before GC invocations=0 (full 0):  
  5.  par new generation   total 9216K, used 4695K [0x03b80000, 0x04580000, 0x04580000)//b1+b2  
  6.   eden space 8192K,  57% used [0x03b80000, 0x04015f50, 0x04380000)  
  7.   from space 1024K,   0% used [0x04380000, 0x04380000, 0x04480000)  
  8.   to   space 1024K,   0% used [0x04480000, 0x04480000, 0x04580000)  
  9.  tenured generation   total 10240K, used 0K [0x04580000, 0x04f80000, 0x04f80000)//此时老年代为空  
  10.    the space 10240K,   0% used [0x04580000, 0x04580000, 0x04580200, 0x04f80000)  
  11.  compacting perm gen  total 12288K, used 2105K [0x04f80000, 0x05b80000, 0x08f80000)  
  12.    the space 12288K,  17% used [0x04f80000, 0x0518e450, 0x0518e600, 0x05b80000)  
  13. No shared spaces configured.  
  14. [GC [ParNew: 4695K->409K(9216K), 0.0049519 secs] 4695K->4505K(19456K), 0.0049944 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]   
  15. Heap after GC invocations=1 (full 0):  
  16.  par new generation   total 9216K, used 409K [0x03b80000, 0x04580000, 0x04580000)//b1  
  17.   eden space 8192K,   0% used [0x03b80000, 0x03b80000, 0x04380000)  
  18.   from space 1024K,  39% used [0x04480000, 0x044e6610, 0x04580000)  
  19.   to   space 1024K,   0% used [0x04380000, 0x04380000, 0x04480000)  
  20.  tenured generation   total 10240K, used 4096K [0x04580000, 0x04f80000, 0x04f80000)//b2  
  21.    the space 10240K,  40% used [0x04580000, 0x04980010, 0x04980200, 0x04f80000)  
  22.  compacting perm gen  total 12288K, used 2105K [0x04f80000, 0x05b80000, 0x08f80000)  
  23.    the space 12288K,  17% used [0x04f80000, 0x0518e450, 0x0518e600, 0x05b80000)  
  24. No shared spaces configured.  
  25. }  
  26. step 4  
  27. step 5  
  28. {Heap before GC invocations=1 (full 0):  
  29.  par new generation   total 9216K, used 4669K [0x03b80000, 0x04580000, 0x04580000)//b1+b3(step3)  
  30.   eden space 8192K,  52% used [0x03b80000, 0x03fa9098, 0x04380000)  
  31.   from space 1024K,  39% used [0x04480000, 0x044e6610, 0x04580000)  
  32.   to   space 1024K,   0% used [0x04380000, 0x04380000, 0x04480000)  
  33.  tenured generation   total 10240K, used 4096K [0x04580000, 0x04f80000, 0x04f80000)//b2  
  34.    the space 10240K,  40% used [0x04580000, 0x04980010, 0x04980200, 0x04f80000)  
  35.  compacting perm gen  total 12288K, used 2111K [0x04f80000, 0x05b80000, 0x08f80000)  
  36.    the space 12288K,  17% used [0x04f80000, 0x0518fe08, 0x05190000, 0x05b80000)  
  37. No shared spaces configured.  
  38. [GC [ParNew: 4669K->43K(9216K), 0.0008256 secs] 8765K->4548K(19456K), 0.0008701 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]   
  39. Heap after GC invocations=2 (full 0):  
  40.  par new generation   total 9216K, used 43K [0x03b80000, 0x04580000, 0x04580000)//step3分配的b3对象空间被回收  
  41.   eden space 8192K,   0% used [0x03b80000, 0x03b80000, 0x04380000)  
  42.   from space 1024K,   4% used [0x04380000, 0x0438ad90, 0x04480000)  
  43.   to   space 1024K,   0% used [0x04480000, 0x04480000, 0x04580000)  
  44.  tenured generation   total 10240K, used 4505K [0x04580000, 0x04f80000, 0x04f80000)//b1+b2  
  45.    the space 10240K,  43% used [0x04580000, 0x049e6590, 0x049e6600, 0x04f80000)  
  46.  compacting perm gen  total 12288K, used 2111K [0x04f80000, 0x05b80000, 0x08f80000)  
  47.    the space 12288K,  17% used [0x04f80000, 0x0518fe08, 0x05190000, 0x05b80000)  
  48. No shared spaces configured.  
  49. }  
  50. Heap  
  51.  par new generation   total 9216K, used 4303K [0x03b80000, 0x04580000, 0x04580000)//b3(step5)  
  52.   eden space 8192K,  52% used [0x03b80000, 0x03fa8fe0, 0x04380000)  
  53.   from space 1024K,   4% used [0x04380000, 0x0438ad90, 0x04480000)  
  54.   to   space 1024K,   0% used [0x04480000, 0x04480000, 0x04580000)  
  55.  tenured generation   total 10240K, used 4505K [0x04580000, 0x04f80000, 0x04f80000)//b1+b2  
  56.    the space 10240K,  43% used [0x04580000, 0x049e6590, 0x049e6600, 0x04f80000)  
  57.  compacting perm gen  total 12288K, used 2116K [0x04f80000, 0x05b80000, 0x08f80000)  
  58.    the space 12288K,  17% used [0x04f80000, 0x051913c8, 0x05191400, 0x05b80000)  
  59. No shared spaces configured.  

如果修改MaxTenuringThreshold的值为2，从打印日志中可以发现，最终老年代的内存使用量为4096KB=4M，也就是说b1没有晋升至老年代

上面是Minor GC的运行状况，如果是Full GC呢：

[java]  view plain  copy
  1. //-XX:+UseParNewGC -Xms20m -Xmx20m -Xmn10m -XX:+PrintHeapAtGC -XX:+PrintGCDetails   
  2. //-XX:MaxTenuringThreshold=1  
  3. public class test {  
  4.     static int mb = 1024*1024;  
  5.       
  6.     public static void main(String[] args) {  
  7.         byte[] b1 = new byte[1*mb/4];  
  8.         System.gc();  
  9.     }  
  10. }  

这里我们使用的是Full GC，也就是老年代的GC。

Full GC通常至少伴随着一次Minor GC（并非绝对），看下面日志，这里的Minor GC应该至少发生了2次，一次Minor GC是不会把b1移动至老年代的

[plain]  view plain  copy
  1. {Heap before GC invocations=0 (full 0):  
  2.  par new generation   total 9216K, used 599K [0x03b80000, 0x04580000, 0x04580000)//b1  
  3.   eden space 8192K,   7% used [0x03b80000, 0x03c15f40, 0x04380000)  
  4.   from space 1024K,   0% used [0x04380000, 0x04380000, 0x04480000)  
  5.   to   space 1024K,   0% used [0x04480000, 0x04480000, 0x04580000)  
  6.  tenured generation   total 10240K, used 0K [0x04580000, 0x04f80000, 0x04f80000)//老年代为空  
  7.    the space 10240K,   0% used [0x04580000, 0x04580000, 0x04580200, 0x04f80000)  
  8.  compacting perm gen  total 12288K, used 2104K [0x04f80000, 0x05b80000, 0x08f80000)  
  9.    the space 12288K,  17% used [0x04f80000, 0x0518e278, 0x0518e400, 0x05b80000)  
  10. No shared spaces configured.  
  11. [Full GC (System) [Tenured: 0K->404K(10240K), 0.0069434 secs] 599K->404K(19456K), [Perm : 2104K->2104K(12288K)], 0.0069992 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]   
  12. Heap after GC invocations=1 (full 1):  
  13.  par new generation   total 9216K, used 0K [0x03b80000, 0x04580000, 0x04580000)//新生代为空  
  14.   eden space 8192K,   0% used [0x03b80000, 0x03b80000, 0x04380000)  
  15.   from space 1024K,   0% used [0x04380000, 0x04380000, 0x04480000)  
  16.   to   space 1024K,   0% used [0x04480000, 0x04480000, 0x04580000)  
  17.  tenured generation   total 10240K, used 404K [0x04580000, 0x04f80000, 0x04f80000)//b1  
  18.    the space 10240K,   3% used [0x04580000, 0x045e5130, 0x045e5200, 0x04f80000)  
  19.  compacting perm gen  total 12288K, used 2104K [0x04f80000, 0x05b80000, 0x08f80000)  
  20.    the space 12288K,  17% used [0x04f80000, 0x0518e278, 0x0518e400, 0x05b80000)  
  21. No shared spaces configured.  
  22. }  
  23. Heap  
  24.  par new generation   total 9216K, used 327K [0x03b80000, 0x04580000, 0x04580000)  
  25.   eden space 8192K,   4% used [0x03b80000, 0x03bd1f98, 0x04380000)  
  26.   from space 1024K,   0% used [0x04380000, 0x04380000, 0x04480000)  
  27.   to   space 1024K,   0% used [0x04480000, 0x04480000, 0x04580000)  
  28.  tenured generation   total 10240K, used 404K [0x04580000, 0x04f80000, 0x04f80000)  
  29.    the space 10240K,   3% used [0x04580000, 0x045e5130, 0x045e5200, 0x04f80000)  
  30.  compacting perm gen  total 12288K, used 2116K [0x04f80000, 0x05b80000, 0x08f80000)  
  31.    the space 12288K,  17% used [0x04f80000, 0x05191190, 0x05191200, 0x05b80000)  
  32. No shared spaces configured.  

四：动态对象年龄判定

为了使内存分配更加灵活，虚拟机并不要求对象年龄达到MaxTenuringThreshold才晋升老年代

如果Survivor区中相同年龄所有对象大小的总和大于Survivor区空间的一半，年龄大于或等于该年龄的对象在Minor GC时将复制至老年代

[java]  view plain  copy
  1. //-XX:+UseParNewGC -Xms20m -Xmx20m -Xmn10m  -XX:MaxTenuringThreshold=10  
  2. //-XX:+PrintTenuringDistribution  
  3. public class Test {  
  4.     static int mb = 1024*1024;  
  5.       
  6.     public static void main(String[] args) {  
  7.         System.out.println("step 1");  
  8.         byte[] b1 = new byte[1*mb/4];  
  9.         byte[] b3 = new byte[4*mb];  
  10.         byte[] b4 = new byte[4*mb];//GC  
  11.         System.out.println("step 2");  
  12.         byte[] b2 = new byte[1*mb/4];//可以尝试1*mb/2,然后观察日志  
  13.         b4 = null;  
  14.         System.out.println("step 3");  
  15.         b4 = new byte[4*mb];//GC  
  16.         System.out.println("step 4");  
  17.         b4 = null;  
  18.         b4 = new byte[4*mb];//GC  
  19.     }  
  20. }  

先来介绍一个设置-XX:+PrintTenuringDistribution，这个参数很有意思，会在Minor GC时打印Survivor区内存容量的一半，晋升老年代年龄阀值，Survivor区中的对象大小以及对象年龄

根据启动参数的设置，Survivor大小的一半是524288B，也就是512KB。第一次GC后，b1依然存活，故年龄变为1。第二次GC后，b1和b2依然存活，故b1的年龄变为2，b2的年龄为1。b1+b2的大小加起来超过了Survivor区容量的一半，此时会修改Survivor区晋升老年代年龄阀值为2（如果移动年龄为2的对象可以使Survivor去的内存使用降至512KB以内，则只移动年龄为2的对象，否则将会同时移动年龄为1的对象）。第三次GC时，将年龄等于晋升阀值的对象移动至老年代，执行GC，GC结束后，b1依然在Survivor区（当然可能从Survivor from区拷贝至了Survivor to区），此时b1的年龄变为2。这时Survivor区的使用内存没有达到512M，修改Survivor区晋升老年代年龄阀值为参数设置的10。

[plain]  view plain  copy
  1. step 1  
  2.   
  3. Desired survivor size 524288 bytes, new threshold 10 (max 10)  
  4. - age   1:     412800 bytes,     412800 total  
  5. step 2  
  6. step 3  
  7.   
  8. Desired survivor size 524288 bytes, new threshold 2 (max 10)  
  9. - age   1:     262160 bytes,     262160 total  
  10. - age   2:     412800 bytes,     674960 total  
  11. step 4  
  12.   
  13. Desired survivor size 524288 bytes, new threshold 10 (max 10)  
  14. - age   1:        136 bytes,        136 total  
  15. - age   2:     262160 bytes,     262296 total  

最后，为什么在第三次GC后，Survivor区还存在一个大小为136B，年龄为1的被使用内存空间？

我猜测，虽然Minor GC时Survivor区没有足够的空间完成GC时会租借老年代的内存，但是在Survivor区依然保存了一个指向老年代租借内存起始地址的引用

五：空间分配担保

这个前面已经出现过多次了，由于新生代使用复制算法，当Minor GC时如果存活对象过多，无法完全放入Survivor区，就会向老年代借用内存存放对象，以完成Minor GC

在触发Minor GC时，虚拟机会先检测之前GC时租借的老年代内存的平均大小是否大于老年代的剩余内存，如果大于，则将Minor GC变为一次Full GC，如果小于，则查看虚拟机是否允许担保失败（-XX:+/-HandlePromotionFailure。从jdk6.0开始，允许担保失败已变为HotSpot虚拟机所有收集器默认设置，虚拟机将不再识别该参数设置，详见JDK-6990095 : Deprecate and eliminate -XX:-HandlePromotionFailure），如果允许担保失败，则只执行一次Minor GC，否则也要将Minor GC变为一次Full GC（直到GC结束时才能确定到底有多少对象需要被移动至老年代，所以在GC前，只能使用粗略的平均值进行判断）

zhuguorong11
关注
专栏目录
内存分配与回收策略
宋常华的博客
06-30 435
Java技术体系所提倡的自动内存管理最终可以归结为自动化地解决了两个问题：给对象分配内存以及回收分配给对象的内存，关于回收内存，前几篇博客已经介绍了虚拟机的垃圾收集器体系以及运行原理，现在我们讨论一下对象分配内存。 对象分配内存，往大方向讲，就是在堆上分配，对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配，少数情况下也可能会直接在老年代分配，总之分配的规
JVM笔记4：Java内存分配策略
weixin_30802273的博客
10-29 183
简单来说，对象内存分配主要是在堆中分配。但是分配的规则并不是固定的，取决于使用的收集器组合以及JVM内存相关参数的设定 以下介绍几条基本规则（使用的ParNew+Serial Old收集器组合）： 一，对象优先在新生代Eden区分配 //-XX:+UseParNewGC -Xms20m -Xmx20m -Xmn10m -XX:+PrintHeapAtGC -XX:+PrintGC...
开启 GC 日志
ConstXiong
01-10 1309
之前写过一个例子，展示对象循环引用仍然会被 JVM 的垃圾收集器回收。 代码如下： packageconstxiong.jvm.gc; /** *引用计数 */ publicclassReferenceCount{ publicReferenceCountholder; /** *占用5M */ privatebyte[]appendMemory=newbyte[5*1024*1024]; publi...
java虚拟机没有分配足够的内存_《深入理解Java虚拟机》内存分配策略
weixin_42416119的博客
02-24 282
上节学习回顾1、判断对象存活算法：引用计数法和可行性分析算法2、垃圾收集算法：标记-清除算法、复制算法、标记-整理算法3、垃圾收集器：Serial：新生代收集器，采用复制算法，单线程。ParNew：新生代收集器，采用复制算法，多线程。Parallel Scavenge：新生代收集器，采用复制算法，多线程，注重吞吐量。Serial Old：老年代收集器，采用标记-整理算法，单线程。Parallel ...
内存溢出的一些个学习整理
chencongbin5的博客
03-04 494
tomcat/bin/catalina.sh 里面加句话 在以前的JAVA_OPTS 里面加 -verbose:gc -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintHeapAtGC -Xloggc:/web1gc.log  我电脑里的是这个鬼: JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=d
Java虚拟机内存分配探析.pdf
最新发布
12-27
Java虚拟机内存分配主要涉及到两种主要的内存区域：堆（Heap）和栈（Stack）。这两种内存区域在程序执行过程中有着不同的角色和管理策略。 栈内存主要用于存储基本类型变量（如int、float等）和对象的引用。在函数...
JAVA虚拟机内存分配与回收机制[文].pdf
10-11
JAVA虚拟机内存分配与回收机制 JAVA虚拟机的内存分配与回收机制是JAVA语言的核心机制之一。该机制将内存划分为两种：栈内存和堆内存。 栈内存是用于存放基本类型的变量和对象的引用变量。在函数中定义的变量和对象...
JAVA虚拟机内存分配机制
03-07
JAVA虚拟机内存分配机制是Java程序执行过程中内存管理的核心部分，它涉及到程序的性能和效率。Java虚拟机（JVM）内存主要分为两大部分：栈内存和堆内存。 栈内存主要存储程序运行过程中的局部变量，包括基本类型...
Java虚拟机内存分配机制详解
Java内存分配是Java虚拟机（JVM）中的一种重要机制，它负责管理Java程序的内存资源。在JVM中，内存分配是通过垃圾收集器和内存分配策略来实现的。 Java虚拟机中有多种类型的内存区域，包括程序计数器、Java虚拟机栈...
java虚拟机内存分配和垃圾回收
05-23
Java虚拟机的内存分为两个部分：堆内存和非堆内存。 堆内存是Java程序运行时动态分配的内存空间，用于存储对象实例，它可以通过-Xms和-Xmx参数来设置初始大小和最大大小。当堆内存不足时，Java虚拟机会自动进行垃圾...
JVM中的内存分配策略
Alan_Xiang的博客
11-02 759
对象的内存分配，从大方向上将，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地在栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况也可能直接分配在老年代中，分配的规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。 　　下面讲解集中最普遍的内存分配规则，并通过代码
深入理解java虚拟机-3 内存分配与回收策略
08-03 529
Java技术体系中的自动化内存管理最终可以分为两个问题:给对象分配内存以及回收分配给对象的内存 下面使用Serial 和serial Old收集器来验证分配策略 1,对象优先在Eden分配 新生区分 Eden与Serivivor 默认比例8:1 大多数情况下,对象在新生代Eden中分配,新生代没有空间时,虚拟机发起一场Minor GC -XX:+PrintfGCDetails 在垃圾回收
Subversion 导致Eclipse自动关闭
枯鸦专栏
06-20 2550
转自：http://sjsky.iteye.com/blog/850858
Java虚拟机--堆的配置参数（四）
老赫的私人厨房
03-27 1806
最大堆和初始堆的设置 说明： Java进程启动时，虚拟机就会分配一块初始堆空间，可以使用参数-Xms指定这块空间的大小；如果初始堆空间耗尽，虚拟机会对堆空间继续扩展，其扩展上限为最大堆空间，最大堆空间可以使用参数-Xmx指定； 示例1：通过此例，说明最大堆，初始堆以及系统可用内存的含义和彼此之间的关系： public class HeapAlloc { public stat
【转】JVM内存管理：深入垃圾收集器与内存分配策略
weixin_34235457的博客
12-01 92
2019独角兽企业重金招聘Python工程师标准>>> ...
三、JVM垃圾回收与内存分配策略
冷血天狼的博客
07-27 296
1.内存分配策略 对象优先在eden区分配 简单来说，对象内存分配主要在堆中分配，但是分配的规则并不是固定的，取决于使用的收集器组合以及jvm内存相关参数的设定 以下介绍几条基本规则(使用的ParNew+Serial Old收集器组合) //-XX:+UseParNewGC-Xms20m-Xmx20m-Xmn10m-XX:+PrintHeapAtGC-XX:+PrintGCDet...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值