1.虚拟机对象的创建
虚拟机遇到new指令
(1) 类加载：
检查该指令参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载，解析和初始化过。如果没有，必须先执行相应的类加载过程；
(2) 为新生对象分配内存：
对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来；
分配内存方式：
— 指针碰撞：Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界
点的指示器，那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离（使用Serial，ParNew等带
Compact过程的收集器时，采用的分配算法是指针碰撞）
— 空闲列表：Java堆中的内存并不是规整的，已使用的内存和空闲的内存并不是规整的，已使用的内存和空闲的内存相互交
错，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表
中找到一块足够大的空间划分给对象实例，并更新列表上的记录（使用CMS这种基于Mark-Sweep算法收集器时，采用空闲
列表）
对象创建在虚拟机中是频繁的并发情况下线程不安全：
即：正在给A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。
解决方案：
— 对分配内存空间的动作进行同步处理：实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性；
— 把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配
缓冲（TLAB），虚拟机是否使用TLAB，可以通过-XX:+/-UseTLAB参数来设定。
(3) 将分配到的内存空间都初始化为零值（不包括对象头）：
如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行
该操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值
(4) 对对象进行必要的设置：
该对象是哪个类的实例，如何才能找到类的元数据，对象的hashCode，对象的GC分代年龄等信息。
这些信息存放在对象的对象头（Object Header）之中。
(5) 执行init方法初始化：
在上面工作完成之后，从虚拟机角度看，一个新的对象已经产生了，但从Java程序的视角来看，对象创建才刚开始，
执行<init>方法进行初始化，这样一个真正的对象才算完全产生出来
2.虚拟机对象的内存布局
对象在内存中存储的布局可以分为：对象头（Header），实例数据（Instance Data）和对齐填充（Padding）。
(1) 虚拟机对象头包含：
— 用于存储对象自身的运行时数据：HashCode，GC分代年龄，锁状态标志，线程持有的锁，偏向线程ID，偏向时间戳
— 类型指针：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例
(2) 实例数据部分：
对象真正存储的有效信息，也是在程序代码中所定义的各种类型的字段内容。父类继承下来的和子类中定义的，都需要记录起来。
这部分存储顺序会受到虚拟机分配策略参数和字段在Java源码中定义顺序的影响。
默认分配策略：
— longs/doubles, ints, shorts/chars, bytes/booleans, oops(Ordinary Object Pointers), 从分配策略可以看出相同宽度的字段总
是被分配到一起。在满足这个条件的情况下，父类中定义的变量会出现在子嘞之前。如果CompactFields参数值为true（默认
为true），那么子类之中较窄的变量也可能会插入到父类变量的空隙之中。
(3) 对齐填充：
对齐填充并不是必然存在的，也没有特殊含义，仅仅起着占位符的作用。HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，即对象的大小必须是8字节的整数倍。而对象头部分正好是8字节的倍数（1或2倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补齐全。
3.对象的访问定位
Java程序通过栈上的reference数据来操作堆上的具体对象。
对象的访问方式：
--句柄：优点是reference中存储的是稳定的句柄地址，对象被移动时只改变句柄中的实例数据指针，reference本身不需要改变
--直接指针：优点是速度快，节省了一次指针定位开销
4.OOM异常处理
-Xms：堆的最小值
-Xmx：堆的最大值（最大堆容量）
堆的最小值与最大值设成一样即可避免自动扩展
-XX:+HeapDumpOnOutOfMemoryError：虚拟机在出现内存溢出异常时可以Dump出当前的内存堆转储快照
-XX:MaxPermSize：最大方法区容量
-Xss：栈内存容量
(1)Java堆溢出
首先要分清是内存泄漏还是内存溢出：
— 内存泄漏（Memory Leak）可以通过dump文件分析泄漏对象到GC Roots的引用链。找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收他们的。
— 内存溢出（Memory Overflow）：存在某些对象生命周期过长，持有状态时间过长，尝试减少程序运行期的内存消耗
(2)虚拟机栈和本地方法栈溢出
32位Windows系统限制为2GB。虚拟机提供参数来控制Java堆和方法区这两部分内存最大值。剩余2GB内存 - Xmx（最大堆容量） - MaxPermSize（最大方法区容量） - 程序计数器消耗内存（可忽略不计），剩下的内存由虚拟机栈和本地方法栈所有。每个线程分配到栈容量越大，可建立的线程数就越少，就余额容易耗尽内存。
因此，若为建立过多线程导致内存溢出时，在不能减少线程数量时应当减少最大堆和减少栈容量来换取更多线程。
(3)方法区和运行时常量池溢出
运行时常量池是方法区的一部分
eg：String.intern()
Native方法，
作用：如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；
否则将此String对象包含的字符串添加到常量池中，并返回此String对象的引用
/**
* OOM后跟随提示：PermGenspace说明是永久代内存溢出
* JDK1.6将出现OutOfMemory:PermGenspace
* JDK1.7中不出现错误
* JDK1.6及之前的版本将常量池分配在永久代内，可以通过配置-XX:PermSize -XX:MaxPermSize限制方法区大小，
* 从而间接限制常量池的容量
*/
public class RuntimeConstantPoolOOM {
public static void main(String[] args) {
//使用List保持着常量池引用，避免Full GC回收常量池行为
List<String> list = new ArrayList<String>();
int i = 0;
while (true) {
list.add(String.valueOf(i++).intern());
System.out.println(i);
}
}
}
public class RuntimeConstantPoolOOM {
public static void main(String[] args) {
String str1 = new StringBuilder("计算机").append("软件").toString();
System.out.println(str1.intern() == str1);
String str2 = new StringBuilder("ja").append("va").toString();
System.out.println(str2.intern() == str2);
}
}
JDK1.7在常量池中记录首次出现的实例引用，intern()返回的引用和由StringBuilder创建的那个字符串实例是同一个，
若字符串常量池中已经有它的引用了，不符合首次出现的原则，则返回false
方法区内存溢出：
— 方法区存放Class相关信息：类名/访问修饰符/常量池/字段描述...
— 运行时产生大量的类（持续创建类）去填满方法区，直到溢出
— 当前很多主流框架：Spring，Hibernate，在类进行增强时，都会使用到CGLib这类字节码技术，增强的类越多，就需要越大的方法区来保证动态生成的Class可以加载入内存
— Caused by:java.lang.OutOfMemoryError:PermGen space
(4)本机直接内存溢出
DirectMemory容量可以通过-XX:MaxDirectMemorySize指定，若不指定则默认与Java堆最大值(-Xmx指定)一样。
由DirectMemory导致的内存溢出，一个明显的特征就是在Heap Dump文件中不会看见明星异常，若OOM时Dump文件很小，程序又直接或间接使用了NIO，则需要考虑检查下是否为本机直接内存溢出
标签：种类 ons 布局 内存 window font nio xmx add
原文地址：http://blog.51cto.com/turnsole/2058300
