方法区在jdk7及jdk8的落地实现:
在jdk8中,终于完全废弃了永久代的概念,改用与JRockit、J9一样在本地内存中实现的元空间(Metaspace)来代替
元空间的本质和永久代类似,都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于:元空间不再虚拟机设置的内存中,而是使用本地内存(PC内存)。
永久代、元空间并不只是名字变了。内部结构也调整了。
根据《Java虚拟机规范》的规定,如果方法区无法满足新的内存分配需求时,将抛出OOM异常.。
方法区的大小不必是固定的,jvm可以根据应用的需要动态调整。
jdk7及以前(永久代):
-XX:PermSize
来设置永久代初始分配空间。默认值是20.75M-XX:MaxPermSize
来设定永久代最大可分配空间。32位机器默认是64M,64位机器模式是82Mjdk8及以后(元空间):
-XX:MetaspaceSize
和-XX :MaxMetaspaceSize
指定,替代上述原有的两个参数。-XX:MetaspaceSize
是21M,-XX:MaxMetaspaceSize
的值是-1, 即没有限制。-XX:MetaspaceSize
: 设置初始的元空间大小。对于一个64位的服务器端JVM来说, 其默认的-XX :MetaspaceSize
值为21MB.这就是初始的高水位线,一旦触及这个水位线,Full GC将会被触发并卸载没用的类(即这些类对应的类加载器不再存活),然后这个高水位线将会重置。新的高水位线的值取决于GC后释放了多少元空间。如果释放的空间不足,那么在不超过MaxMetaspaceSize时,适当提高该值。如果释放空间过多,则适当降低该值。- XX :MetaspaceSize
设置为一个相对较高的值。1、要解决00M异常或heap space的异常,一般的手段是首先通过内存映像分析工具(如Eclipse Memory Analyzer) 对dump出来的堆转储快照进行分析,重点是确认内存中的对象是否是必要的,也就是要先分清楚到底是出现了内存泄漏(Memory Leak)还是内存溢出(Memory 0verflow) 。
2、如果是内存泄漏,可进一步通过工具查看泄漏对象到GC Roots 的引用链(堆当中的闲置对象由于引用链的引用关系无法被回收,虽然它已经属于闲置的资源)。于是就能找到泄漏对象是通过怎样的路径与GCRoots相关联并导致垃圾收集器无法自动回收它们的。掌握了泄漏对象的类型信息,以及GC Roots引用链的信息,就可以比较准确地定位出泄漏代码的位置。
3、如果不存在内存泄漏,换句话说就是内存中的对象确实都还必须存活着,那就应当检查虚拟机的堆参数(一Xmx与一Xms) ,与机器物理内存对比看是否还可以调大,从代码_上检查是否存在某些对象生命周期过长、持有状态时间过长的情况,尝试减少程序运行期的内存消耗。
《深入理解Java虚拟机》书中对方法区存储内容描述如下:它用于存储已被虚拟机加载的 类型信息、常量、静态变量、即时编译器编译后的代码缓存等。
类型信息
对每个加载的类型( 类class、接口interface、枚举enum、注解annotation),JVM必须在方法区中存储以下类型信息:
域信息(成员变量)
方法信息(method)
JVM必须保存所有方法的以下信息,同域信息一样包括声明顺序:
non-final的类变量(非声明为final的static静态变量)
以下代码不会报空指针异常:
public class MethodAreaTest {
public static void main(String[] args) {
Order order = null;
order.hello();
System.out.println(order.count);
}
}
class Order {
public static int count = 1;
public static final int number = 2;
public static void hello() {
System.out.println("hello!");
}
}
全局常量(static final):
与被声明为final的类变量的处理方法则不同,每个全局常量在编译的时候就被分配了。
代码解析
Order.class字节码文件,右键Open in Teminal打开控制台,使用javap -v -p Order.class > tst.txt 将字节码文件反编译并输出为txt文件,可以看到被声明为static final的常量number在编译的时候就被赋值了,这不同于没有被final修饰的static变量count是在类加载的准备阶段才被赋值(还记得clinit吗)。
public static int count;
descriptor: I
flags: ACC_PUBLIC, ACC_STATIC
public static final int number;
descriptor: I
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
ConstantValue: int 2
运行时常量池
首先明确:只有HotSpot才有永久代。 BEA JRockit、IBM J9等来说,是不存在永久代的概念的。原则上如何实现方法区属于虛拟机实现细节,不受《Java虚拟机规范》管束,并不要求统一。
Hotspot中 方法区的变化:
/**
* 《深入理解Java虚拟机》中的案例:
* staticObj、instanceObj、localObj存放在哪里?
*/
public class StaticObjTest {
static class Test {
static ObjectHolder staticObj = new ObjectHolder();
ObjectHolder instanceObj = new ObjectHolder();
void foo() {
ObjectHolder localObj = new ObjectHolder();
System.out.println("done");
}
}
private static class ObjectHolder {
}
public static void main(String[] args) {
Test test = new StaticObjTest.Test();
test.foo();
}
}
staticObj变量随着Test的类型信息存放在堆中,instance0bj成员变量随着Test的对象实例存放在Java堆,localobject局部变量则是存放在foo()方法栈帧的局部变量表中。
java.lang.Class对象,它们从来都是“普通”Java对象,跟其它Java对象一样存在普通的Java堆(GC堆的一部分)里。
有些人认为方法区(如Hotspot,虚拟机中的元空间或者永久代)是没有垃圾收集行为的,其实不然。《Java 虚拟机规范》对方法区的约束是非常宽松的,提到可以不要求虚拟机在方法区中实现垃圾收集。事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在(如 JDK11 时期的ZGC 收集器就不支持类卸载)。
一般来说这个区域的回收效果比较难令人满意,尤其是类型的卸载,条件相当苛刻。但是这部分区域的回收有时又确实是必要的。以前 Sun 公司的 Bug 列表中,曾出现过的若干个严重的 Bug 就是由于低版本的 Hotspot 虚拟机对此区域未完全回收而导致内存泄漏。
方法区的垃圾收集主要回收两部分内容:常量池中废奔的常量和不再使用的类型。
常量池中废奔的常量
常量池中不再使用的类型
常量池中不再使用的类型
判定一个常量是否“废弃”还是相对简单,而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件:
Java虛拟机被允许对满足上述三个条件的无用类进行回收,这里说的仅仅是“被允许”,而并不是和对象一样,没有引用了就必然会回收。关于是否要对类型进行回收,HotSpot虚拟机提供了一Xnoclassgc 参数进行控制,还可以使用一verbose:class以及一XX: +TraceClass一Loading、一XX:+TraceClassUnLoading查 看类加载和卸载信息
在大量使用反射、动态代理、CGLib等字节码框架,动态生成JSP以及oSGi这类频繁自定义类加载器的场景中,通常都需要Java虚拟机具备类型卸载的能力,以保证不会对方法区造成过大的内存压力。
百度
三面:说一下JVM内存模型吧,有哪些区?分别干什么的?
蚂蚁金服:
Java8的内存分代改进
JVM内存分哪几个区,每个区的作用是什么?
一面: JVM内存分布/内存结构?栈和堆的区别?堆的结构?为什么两个survivor区?
二面: Eden和Survior的比例分配
小米:
jvm内存分区,为什么要有新生代和老年代
字节跳动:
二面: Java的内存分区
二面:讲讲jvm运行时数据库区
什么时候对象会进入老年代?
京东:
JVM的内存结构,Eden和Survivor比例 。
JVM内存为什么要分成新生代,老年代,持久代。新生代中为什么要分为Eden和Survivor。
天猫:
一面: Jvm内存模型以及分区,需要详细到每个区放什么。
一面: JVM的内存模型,Java8做了什么修改
拼多多:
JVM内存分哪几个区,每个区的作用是什么?
美团:
java内存分配
jvm的永久代中会发生垃圾回收吗?
一面: jvm内存分区,为什么要有新生代和老年代?
come from https://www.cnblogs.com/yanl55555/p/13323128.html
and 尚硅谷