国外photoshop教程网站,沈阳网站建设哪家公司好,网页浏览器哪个好,明星 卡片网站该怎么做一)方法区: java虚拟机中有一个方法区#xff0c;该区域被所有的java线程都是共享#xff0c;虚拟机一启动#xff0c;运行时数据区就被开辟好了#xff0c;官网上说了方法区可以不压缩还可以不进行GC#xff0c;JAVA虚拟机就相当于是接口#xff0c;具体的HotSpot就是虚… 一)方法区:  java虚拟机中有一个方法区该区域被所有的java线程都是共享虚拟机一启动运行时数据区就被开辟好了官网上说了方法区可以不压缩还可以不进行GCJAVA虚拟机就相当于是接口具体的HotSpot就是虚拟机的实现因为永久代还是使用的是JAVA虚拟机的内存 方法区域可以是固定大小的也可以根据计算的需要扩展如果不需要更大的方法区域则可以收缩物理上是不连续的在逻辑上是连续的 1)方法区和JAVA堆一样是各个线程共享的内存区域 2)方法区在JVM启动的时候就被创建并且它的实际的物理内存空间和JAVA队去一样都可以是不连续的 3)方法区的大小和堆空间一样可以选择固定大小或者是可扩展 4)方法去的大小决定了系统可以保存多少各类如果系统定义了太多的类导致方法去溢出虚拟机同样也会抛出内存溢出错误java.lang.OutOfMemory:perm space(永久代空间溢出)或者是java.lang.OutOfMemeory:MeatSpace(元空间空间溢出)比如说大量加载第三方jar包Tomact部署的工程过多大量的动态生成反射类加载大量第三方jar包Tomact部署的应用程序太多一个简单的代码可能要加载很多类动态生成反射类比如说动态代理元空间不在虚拟机设置的内存中而是使用本地内存物理内存字符串常量池和静态变量也会变化但是如果超过本地内存上限也会发生OOM metaSpace因为方法区是不共享的所以说只能有一个类可以调用类加载器实现类加载 5)关闭JVM就会释放这个区域的内存JDK7以前习惯上把方法区称之为是永久代JDK8开始使用元空间替代了永久代本质上方法区和永久代并不是等价的但是仅仅是针对于HotSpot虚拟机而言的也就是JAVA虚拟机规范对于如何实现方法区不会做统一要求现在来看使用永久代共容易出现OOM 6)元空间的本质和永久代类似都是对JVM规范中方法去的实现不过元空间和永久代最大的区别在于元空间不在虚拟机设置的内存中二时使用的是本地内存永久代和元空间不光名字变了况且内部结构也调整了根据JAVA虚拟机规范规定如果方法去无法满足新的内存分配的需求的时候会抛出OOM异常本地内存是无限大的况且静态变量字符串常量池等等也会变化 -XX:MetaspaceSize100m-XX:MaxMetaspaceSize100m 一般在实际开发中会进行设置MetaspaceSize不会设置MaxMetaspaceSize是默认值-1即可这个Metaspace一开始要设置的大一些为了避免频繁的发生FullGC导致调整水平线 方法区用于存放已经被虚拟机加载的类型信息常量静态变量以及即时编译器编译过后的代码缓存 1)类型信息:对于每一个加载的类型(类 class接口 interface枚举Enum注解 annoation)JVM必须在方法中存放一下类型信息: 1)这个类型的完整有效名称(全名包名类名) 2)这个类型直接的父类的完整有效名字(对于interface和java.lang.object都是没有父类的) 3)这个类型的修饰符 4)这个类直接接口的有效列表 2)域信息:就是成员变量的属性JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序域的相关信息包括修饰符关键字等等名称类型修饰符在方法区中也是保留着这个类信息是被哪一个类加载器加载进来的类加载器的信息也是在类的信息中是有纪录的同时类加载也会记录他都加载过那些类彼此相互记录 3)方法信息:操作数栈的深度方法的权限形参局部变量表的深度以及try catch包裹的代码范围信息 上面的这段代码执行也不会出现空指针异常被static和final修饰的量是在编译过程中的准备阶段就被附上初值了 Class文件常量池:每个.Java源文件编译后生成.Class文件中会保存当前类中的字面常量以及符号信息 运行时常量池在.Class文件被加载时.Class文件中的常量池被加载到内存中称为运行时常量池运行时常量池每个类都有一份 字符串常量池(StringTable) :字符串常量池在JVM中是StringTable类实际是一个固定大小的HashTable(一种高效用来进行查找的数据结构)不同JDK版本下字符串常量池的位置以及默认大小是不同的 二)运行时常量池: 方法区中包含了字符串常量池字节码文件内部包含了常量池要想弄清楚方法区需要清楚的理解ClassFile因为本身加载类的信息都在方法区所以要想弄清楚方法区的运行时常量池就需要先学会ClassFile中的常量池 常量池:字面量(1020)字符串本身Systemout等等类型信息这些都会对应着一个符号 类型信息方法引用接口信息只是存储一份节省空间通过符号引用就可以直接找到对应的常量池对应字段的位置 class文件常量池:this也是以字面量的方式及进行存储的 1)方法区的运行时常量池:就是字节码文件中每一个类的接口对应的常量池表在运行时后的一个表示形式类型信息方法字段常量字段属性引用方法引用\ 2)常量池就相当于是一张表JVM指令需要根据这张表来找到要执行的类名方法名参数类型字面量等类型连方法名都被符号引用所代替了class文件常量池被加载到方法去以后就变成了运行时常量池 3)运行时常量池是方法区的一部分常量池表是Class文件的一部分用于存放编译器的生成的各种字面量和符号引用这部分内容将被类加载以后存放到方法区的运行时常量池中 4)运行时常量池在加载类和接口到虚拟机以后就会创建对应的运行时常量池 JVM为每一个已经加载的类型类或者是接口都维护一个常量池池子中的数据项像数组项一样都是通过索引来进行访问的比如说#7 5)运行时常量池中包含着多种不同的常量包括编译时期就已经确定的数值字面量也包括到运行时期解析才可以获得的方法或者是字段引用此时就不是常量池中的符号引用了而是转化成了真实地址运行时常量池相比于class文件常量池的另一个重要特征就是具备动态性String.intern()运行时常量池类似于传统编程语言中的符号表但是它所包含的数据要比符号表要更丰富一些 6)当创建类或者是接口的运行时常量池的时候如果构建运行时常量池的所需要的内存空间方法去所能提供的最大值JVM会抛出OOM异常 三)方法区的迭代: 1)首先先明确一下只有HotsSpot才存在永久代BEA JRockitIBM J9等来说是不存在永久代的概念的原则上如何实现方法区属于虚拟机实现的内部细节不受JAVA虚拟机规范约束并不要求统一 2)JDK6以前只有永久代静态变量就存放在永久代上面 3)JDK7存在永久代但是已经逐步去除永久代字符串常量池静态变量仍然在堆里面 4)JDK8没有永久代类型信息字段方法常量仍然保存在本地内存的元空间但是字符串常量池静态变量仍然在堆空间里面 1)之所以要取消永久代是因为JAVA官方收购了JRocket之后将JRocket和HotSpot进行整合的时候因为JROCKet没有永久代所以就把永久代给移除了 2)为什么JRocket没有永久代呢 随着JAVA8的到来HotSpot VM中再也见不到永久代了但是这并不意味着类的元数据信息也消失了这些数据被动到了一个和堆没有任何关系的本地内存区域这个区域叫做元空间由于类的元数据信息分配在本地内存中元空间最大可分配空间就是系统可用内存空间这项改动是非常有必要的因为: 2.1)为永久代设置空间大小很难确定:在某些场景下如果说动态的加载类过多很容易产生Perm区的OOM比如说在某一个Web工程中因为功能点比较多那么在运行过程中要不断地加载很多类但是具体加载的类的多少和大小程序员是很难进行确定的经常出现致命错误空间小容易出现FullGCSTW时间比较长如果发生FullGC以后没有回收什么类就容易出现OOM分配大了浪费空间但是元空间max-1更不容易发生fullGC 2.2)对永久代的调优很困难永久代发生FGCJVM判断常量池废弃的常量和不再使用的类也很浪费时间影响程序执行的性能所以说要尽量少出现FullGC 在JAVA7中方法区的实现是依靠永久代来实现的主要存储的是运行时常量池class类信息等等永久代是JVM运行时运行数据区的一块内存空间可以通过-XX PermSize来设置永久代的大小当内存不够的时候就会触发垃圾回收但是JDK1.8使用元空间来替代方法区的数据存储元空间不属于JVM内存而是本地内存正常情况下元空间是可以无限制的使用本地内存的但是还是可以通过参数来设置JVM元空间的使用内存大小 1)在JDK1.7的永久代是有内存限制的是虚拟内存虽然可以通过参数来进行设置但是JVM加载的class总数是很难确定的所以很容易出现OOM的问题但是元空间是存储在本地内存里面内存的上限是比较大的很好的避免这个问题 2)永久代的对象是通过fullGC进行垃圾回收的也就是和老年代同时实现垃圾回收替换以后简化了fullGC的过程可以不再进行暂停的情况下去并发释放类的数据同时也提升了GC的性能 3)Orcle公司要合并Hotspot和Jrockit的代码但是Jrockit没有永久代 方法区使用的是虚拟机内存和本地内存有一个映射关系JDK8使用本地内存此时元空间大小只是受本地内存的影响是不是虚拟内存是程序员本身设置的通过一定的方式将虚拟内存映射到直接内存中类多方法多不确定到底开辟多大的永久代空间小引起fullGCSTW时间长但是又不能回收最后只能造成OOM如果开辟空间越大也会造成浪费永久代出现full GC对永久代调优是很困难的永久代万一进行垃圾回收判断类和常量不再使用所以说尽量少出现full gc 元空间默认的初始值是21M各种加载的类信息都要存放到方法区里面如果Web应用系统加载的类信息直接大量存放在方法区达到了21M那么此时会触发Full GC不光会回收堆还会回收方法区会对方法区中某一些无用的信息进行回收 方法区容量分配大小的自动扩容机制: 1)假设一次FullGC之后方法区的垃圾回收回收了很多对象剩余的方法区的空间大小是1M那么此时的方法区下一次触发FullGC的内存大小就是回比21M小也就是15M 2)假设这一次FullGC方法区的垃圾回收基本没回收对象那么下一次触发FullGC的达到的空间就会变得更高会根据方法区这一次回收的大小自动做扩容 3)推荐设置此值很容易放满就有可能频繁触发FullGC必须设置此值不要说让方法区进行自动扩容就不会让他每一次进行FullGC进行动态扩容防止大量进行FullGC 静态变量staticObj和Class对象存放在一起而Class对象又是存放在堆空间中的 方法区和永久代有什么区别 方法区是JAVA虚拟机规范时候给的一个概念包括JAVA虚拟机的运行时数据区 但是Hotspot针对于方法区的实现给出了不同的名称 JDK1.7永久代方法区实现但是JDK1.8元空间方法区实现 方法区是定义的名称但是永久代和元空间都是方法区的实现而已 五)JDK1.8方法区有什么优化 1)将元空间改成了直接内存 2)将字符串常量池移动到了堆上 在JAVA开发中最常用的两个类型就是对象和String类型字符串常量池比较大最大的地方就要放在运行数据区的堆空间上 为什么把字符串常量池移动到堆上呢 JDK7中将StringTable存放到了堆空间中因为永久代的回收效率很低在FullGC的时候才会被触发但是FullGC是老年代的空间不足永久代不足的时候才会触发这就导致StringTable回收效率不高而当开发中会有大量的字符串需要被创建回收效率低导致永久代内存不足放到堆里面可以及时的回收内存 四)方法区的垃圾回收:常量池中废弃的常量以及不再使用的类变量 在大量使用到反射动态代理CGLIB等字节码框架动态生成JSP以及频繁的自定义类加载器的场景通常都是需要JAVA虚拟机具有类型卸载的能力来保证不会对方法区有着很大的压力 4.1)类卸载的条件:ZGC不支持类卸载一般来说这个区域的回收效果非常复杂难以让人满意但是这部分区域的回收又是比较必要的 4.2)先来说说方法区中常量池之众所存放的两大类常量:字面量符号引用 字面量是比较接近于JAVA语言层次的常量概念比如说文本字符串被声明成final的常量值等但是符号引用就属于编译原理等方面的概念包括以下三类常量: 1)类和接口的全限定名 2)字段的名称和描述符 3)方法的名称和描述符HotSpot虚拟机对于常量池的回收策略是很明确的只要常量池中的常量没有被任何地方所引用就可以被回收 方法区中的类记录了它是由哪一个加载器进行加载的类的加载器同时也会记录他加载过谁类的加载器都被卸载了那么A也会被干掉但是通常类的加载器是一般不会被回收的 1)严重性:内存溢出内存泄漏: 比如说ThreadLocal没有调用remove 2)内存泄漏最终会导致内存溢出而内存溢出可能是内存泄漏导致的比如说网络IO未释放资源 五)对象的实例化内存布局和访问定位 1)从这个字节码中可以看到stack是操作数栈的深度是2局部变量表一共有两个元素参数是1 2)现在来看Code代码首先执行new字节码的操作指令看到这里是#2然后去找Object首先会进行判断运行时常量池里面是否已经加载了Object类如果没有加载过那么直接使用ClassLoader将java/lang/Object类直接加载到方法区并在堆上开辟内存空间 中间有一个指针进行标识空闲空间和非空闲空间的一个划分区域当存放完成新的对象以后指针会向右移