A memory allocation
1.JVM Architecture
2. runtime data area
3. The memory allocation
two, memory reclamation
1. garbage collection algorithm
2. The garbage collector
three related reference
a memory allocation
JVM Architecture
Before understanding memory allocation automatic memory management, we look at the architecture of the JVM. The result code is compiled into a byte code from the local machine code, through the classes loaded into the virtual machine to execute the program. The main architecture of the JVM as shown below:
JVM architecture
Runtime data area
We can clearly see in the figure above, JVM memory division during the execution of the Java program which will manage the data into a number of different areas, namely, the program counter, Java virtual machine stack, native method stacks, the method area (including runtime constant pool), the heap. Following elaborate.
Program Counter (Program Counter Register)
thread private, will not OOM, is a small memory space, the role can be seen as an indicator byte-code line number of the current thread of execution, because the JVM is multithreaded by thread alternately switching and allocation of processor execution time to achieve, after switching to the thread can be restored to the correct position is performed, each thread requires a separate program counter, between the respective threads independently of each other, independent storage.
Stack Java Virtual Machine (Java Virtual Machine Stacks)
thread private, each creates a thread, the virtual machine creates a virtual machine stack for this thread is the memory model Java virtual machine stack execution method described, each call a method, you It generates a frame stack (stack frame) the method for local variable table storing operation information stack, the method exports, when this method is executed, the stack frame will pop up. This part of the region, if the depth of the stack of requests is too large, StackOverflowError virtual machine may throw an exception if the virtual machine allows a virtual machine stack dynamically expand when the memory is not sufficient to expand the stack, it will throw an OutOfMemoryError.
Native method stacks (Native Method Stack)
thread private, native method stacks and stack virtual machine is similar, except that in the implementation of the native method.
Heap
threads share, almost all object instances and arrays are allocated in this area, is the main area where garbage collection is here (there may be a method area). Java stack may be in a discontinuous physical memory space, as long as continuous logical. From the perspective of memory allocation point of view, shared by the threads of the Java heap may be divided into multiple threads private allocate a buffer (Thread Local Allocation Buffer, TLAB) . From the perspective of memory recovery of view, Java heap can be divided into the old and the new generation's, then fine point there is Eden space, From Survivor space, To Survivor space. If there is no complete examples in the heap memory allocation, and the stack can no longer expand, it throws OOM exception.
Heap
Methods district
threads share for class information storage has been loaded in the virtual machine, constants, static variables, the instant compiled code and other information. When the method of memory allocation area can not meet demand, it throws OOM exception. Runtime constant pool is part of the zone method, mainly used to store generated when compiling literal and symbolic references.
This run the following chart data area may be more image a bit.
Memory Allocation
大多数情况下，对象在新生代Eden区中分配，当Eden区没有足够的空间进行分配时，虚拟机将发起一次新生代GC（Minor GC）。
在设置虚拟机参数的时候，-Xmx20M -Xms20M -Xmn10M -XX:SurvivorRatio=8的含义是-Xmx与-Xms相等限制了堆大小为20MB，-Xmn表示新生代大小为10MB，剩下的10MB分配给老年代，-XX:SurvivorRatio=8表示新生代中Eden区与一个Survivor区空间比例大小为8:1，所以Eden区大小为8192K，一个Survivor区大小为1024K，新生代总可用空间为9216K。
大对象直接进入老年代，大对象是指需要连续内存空间的Java对象，比如很长的字符串及数组。长期存活的对象将进入老年代。
有道题是这样的：
问题
这道题是自己在之前遇到过的，题目本身表达有点歧义，答案是堆和字符串常量池中，当new String("abc")时，其实会先在字符串常量区生成一个abc的对象，然后new String()时会在堆中分配空间，然后此时会把字符串常量区中abc复制一个给堆中的String，故abc应该在堆中和字符串常量区。
二、内存回收
对象是否存活？
垃圾收集器在对堆进行回收前，首先需要判断对象是否存活，即是否可能再被使用。这里就要提到一个引用计数算法，每当一个对象被引用时，计数器就加1，引用失效时就减1,当计数器为0时就不可能被使用了，这是一个简单的判断对象是否存活的算法，但是Java中并没有选用，主要是因为它很难解决对象间相互循环引用的问题。
Java中判断对象是否存活，使用的是根搜索算法，基本思路就是通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连，这个对象就是不可用的。
Java中可以作为GC Roots对象的主要有以下几种：
1）虚拟机栈（栈帧中的本地变量表）中引用的对象
2）方法区中类静态属性引用的对象
3）方法区中常量引用的对象
4）Native方法中引用的对象
垃圾收集算法
在确定哪些内存需要回收后，接下来就是怎么回收的问题了，也就是垃圾收集算法，常用的几种如下：标记-清除算法、复制算法、标记-整理算法以及分代回收算法。
标记-清除算法
这是最基础的收集算法，首先标记出所有需要回收的对象，标记完成后统一回收掉所有被标记的对象。缺点有两个，一个是效率问题，标记和清除过程的效率不高，另一个是空间问题，标记清除后会产生大量的不连续的内存碎片。
复制算法
这个算法主要是为了解决效率问题，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块，当一块的内存用完时，将活着的对象复制到另外一块上面，然后把已经使用过的内存空间清理掉。优点是每次都是对其中一块内存进行回收，不用考虑内存碎片等情况，实现简单，运行高效，缺点是内存缩小为原来的一半。
标记-整理算法
复制收集算法在对象存活率较高时就要执行较多的复制操作，效率会变低，标记整理算法首先标记出所有需要回收的对象，之后让所有存活的对象都向一端移动，然后清理掉端边界以外的内存。
分代收集算法
根据对象的存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，根据各个年代的特点采用适当地收集算法。在新生代中，每次垃圾收集时都有大量对象死去，只有少量存活，就选用复制算法，老年代中因为对象存活率高、没有额外空间进行 分配担保，就采用标记-清理或者标记-整理回收。
垃圾收集器
垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现，下面介绍几种常见的垃圾收集器。
Serial收集器
最基本、历史最悠久的收集器，在JDK 1.3.1之前是新生代收集的唯一选择，它是一个单线程收集器，在工作时必须暂停其他所有的工作线程。
ParNew收集器
Serial收集器的多线程版本，其它方面基本与Serial一致。使用-XX:+UseParNewGC开关来控制使用ParNew+Serial Old收集器组合收集内存；使用-XX:ParallelGCThreads来设置执行内存回收的线程数。
Parallel Scavenge 收集器
吞吐量优先的垃圾回收器，作用在新生代，使用复制算法，关注CPU吞吐量，即运行用户代码的时间/总时间。其它收集器主要尽可能地缩短垃圾收集时用户线程的停顿时间，停顿时间短适合需要与用户交互的程序，而高吞吐量则可以最高效率地利用CPU时间，尽快地完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
Serial Old收集器
Serial收集器的老年代版本，单线程收集器，使用标记-整理算法。
Parallel Old收集器
Parallel Scavenge 收集器的老年代版本，使用标记-整理算法，多线程，这个收集器是JDK 1.6才开始提供的，在此之前新生代的Parallel Scavenge收集器比较尴尬，只能与Serial Old搭配，性能有待提高，Parallel Old出现后与Parallel Scavenge搭配很不错。
CMS（Concurrent Mark Sweep）收集器
致力于获取最短回收停顿时间（即缩短垃圾回收的时间），使用标记清除算法，多线程，优点是并发收集（用户线程可以和GC线程同时工作），停顿小。
G1（Garbage-First）收集器
当今收集器技术发展的最前沿成果之一，G1收集器的主要特点有：
1）并行与并发 能充分利用多CPU、多核环境的硬件优势缩短Stop-The-World停顿的时间
2）分代收集 可以不需要其他收集器配合就能独立管理整个GC堆
3）空间整合 整体上的基于“标记-整理”算法及局部上的基于“复制”算法意味着运作期间不会产生内存空间碎片
4）可预测的停顿
————————————————
版权声明：本文为CSDN博主「HelloWorld搬运工」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wufaliang003/article/details/102474366