1.2 双亲委派机制及其原理

分类：JVM作者：编程之家用户

1. 类加载的过程

　　1.1 类加载器初始化的过程

　　1.2 类加载的过程

　　1.3 类的懒加载

2. jvm核心类加载器

参考博客: https://www.cnblogs.com/ITPower/p/13197220.html

 

一. 双亲委派机制

1.1 什么是双亲委派机制 

我们先来看一个案例:

复制代码

package com.lxl.jvm;
import sun.misc.Launcher;
import java.net.URL;

public class TestJDKClassLoader {
    public static void main(String[] args) {
        System.out.println();
        System.out.println("bootstrap Loader加载一下文件:");
        URL[] urls = Launcher.getBootstrapClassPath().getURLs();
        for (int i = 0; i<urls.length; i++) {
            System.out.println(urls[i]);
        }

        System.out.println();
        System.out.println("extClassLoader加载以下文件");
        System.out.println(System.getProperty("java.ext.dirs"));

        System.out.println();
        System.out.println("appClassLoader加载以下文件");
        System.out.println(System.getProperty("java.class.path"));
    }
}

复制代码

这是打印引导类加载器,扩展类加载器,应用程序类加载器加载的目录. 

我们来看一下: 

引导类加载器加载的文件是:Launcher.getBootstrapClassPath().getURLs()下的文件

扩展类加载器加载的文件是: java.ext.dirs,java扩展类目录

应用程学类加载器,加载的是: java.class.path,java home路径下的所有类

我们来看一下打印结果

复制代码

bootstrap Loader加载一下文件:
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/resources.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/rt.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/sunrsasign.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/jsse.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/jce.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/charsets.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/jfr.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/classes

extClassLoader加载以下文件
/Users/Library/Java/Extensions:/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java

appClassLoader加载以下文件

/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/charsets.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/deploy.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext/dnsns.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext/jaccess.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext/localedata.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext/nashorn.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext/sunec.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/ext/zipfs.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/javaws.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/jce.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/jfr.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/jfxswt.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/jsse.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/management-agent.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/plugin.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/resources.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/rt.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/lib/ant-javafx.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/lib/dt.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/lib/javafx-mx.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/lib/jconsole.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/lib/packager.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/lib/sa-jdi.jar:
/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/lib/tools.jar:
/Users/Downloads/workspace/project-all/target/classes:
/Users/responsitory/org/springframework/boot/spring-boot-starter/2.2.8.RELEASE/spring-boot-starter-2.2.8.RELEASE.jar:
/Users/responsitory/org/springframework/boot/spring-boot/2.2.8.RELEASE/spring-boot-2.2.8.RELEASE.jar:
/Users/responsitory/org/springframework/spring-context/5.2.7.RELEASE/spring-context-5.2.7.RELEASE.jar:
/Users/responsitory/org/springframework/spring-aop/5.2.7.RELEASE/spring-aop-5.2.7.RELEASE.jar:
/Users/responsitory/org/springframework/spring-beans/5.2.7.RELEASE/spring-beans-5.2.7.RELEASE.jar:
/Users/responsitory/org/springframework/spring-expression/5.2.7.RELEASE/spring-expression-5.2.7.RELEASE.jar:
/Users/responsitory/org/springframework/boot/spring-boot-autoconfigure/2.2.8.RELEASE/spring-boot-autoconfigure-2.2.8.RELEASE.jar:
/Users/responsitory/org/springframework/boot/spring-boot-starter-logging/2.2.8.RELEASE/spring-boot-starter-logging-2.2.8.RELEASE.jar:
/Users/responsitory/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar:
/Users/responsitory/ch/qos/logback/logback-core/1.2.3/logback-core-1.2.3.jar:
/Users/responsitory/org/apache/logging/log4j/log4j-to-slf4j/2.12.1/log4j-to-slf4j-2.12.1.jar:
/Users/responsitory/org/apache/logging/log4j/log4j-api/2.12.1/log4j-api-2.12.1.jar:
/Users/responsitory/org/slf4j/jul-to-slf4j/1.7.30/jul-to-slf4j-1.7.30.jar:
/Users/responsitory/jakarta/annotation/jakarta.annotation-api/1.3.5/jakarta.annotation-api-1.3.5.jar:
/Users/responsitory/org/springframework/spring-core/5.2.7.RELEASE/spring-core-5.2.7.RELEASE.jar:
/Users/responsitory/org/springframework/spring-jcl/5.2.7.RELEASE/spring-jcl-5.2.7.RELEASE.jar:
/Users/responsitory/org/yaml/snakeyaml/1.25/snakeyaml-1.25.jar:
/Users/responsitory/org/slf4j/slf4j-api/1.7.30/slf4j-api-1.7.30.jar:


/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar



复制代码




通过观察,我们发现


引导类加载器,确实只加载了java home下的/jre/lib目录下面类


扩展类加载器加载了java扩展目录里面的类


但是,应用程序类加载器,加载的类包含了java home下/jre/lib目录,java home扩展目录下的类,还有responsitory仓库下的类,还有idea的类,还有就是我们的类路径下target的类. 


问题来了,为什么AppClassLoader加载器加载了引导类加载器和扩展类加载器要加载的类呢? 这样加载不是重复了么?


 


其实,不会重复加载,appClassLoader主要加载的类就是target目录下的类,其他目录下的类基本上不会加载. 为什么呢? 这就是下面要说的双亲委派机制.




 


 上面这个图就是双亲委派机制的图. 什么意思呢?


比如: 我现在有一个自定义的java.lxl.jvm.Math类. 首先是由应用程序类加载器去加载java.lxl.jvm.Math类,他要去看他已经加载的类中是否有这个类,如果有,就直接返回回来,如果没有,就委托扩展类加载器去加载. 扩展类加载器去查看已经加载的类是否有java.lxl.jvm.Math,如果有就返回,如果没有就继续委托它的父类引导类加载器去加载. 这时候,我们都知道,Math类是我自己定义的,引导类加载器中不可能有,所以,他就会让扩展类加载器去加载,扩展类加载器中有没有呢? 当然也没有,于是委托应用程序类加载器,ok,应用程序类加载器是有的,于是就可以加载,然后返回了.


 


那么,这里有一个问题,  那就是,由应用程序类加载器首先加载,然后最后又回到了应用程序类加载器. 绕了一圈又回来了,这样是不是有些多此一举呢,循环了两次? 为什么一定要从应用程序类加载器加载呢? 直接从引导类加载器加载不好么?只循环一次啊....


 


其实,对于我们的项目来说,95%的类都是我们自己写的,因此,而我们自己写的类是有应用程序类加载器加载. 其实,应用程序类加载器只有在第一次的时候,才会加载两次. 以后,当再次使用到这个类的时候,直接去问应用程序类加载器,有这个类么? 已经有了,就直接返回了. 


 


 1.2 源码分析双亲委派机制


我们来看一下类加载器.类加载器主要调用的是classLoader.loadClass("com.lxl.Math") 这个方法来实现双亲委派机制的. 根据上面的分析,我们知道,在Launcher类初始化的时候,loadClass是AppClassLoader,那么也就是说,双亲委派机制的起点是AppClassLoader. 


下面我们来看一下源码, 我们采用断点的方式来分析 


 首先,我们在Launcher的AppClassLoader的loadClass(String var1,boolean var2) 这个方法添加一个断点,并将其赋值为我们的com.lxl.jvm.Math类




 


 然后运行Math的main方法,我们来看一下这个类到底是如何被加载的




 


 启动debug调试模式,首先进入了Launch.AppClassLoader.loadClass(....)方法




 


 我们来具体看看这个方法的实现




 


上面都是在做权限校验,我们看重点代码. 重点代码是调用了super.loadClass(var1,var2),而这个super是谁呢? 我们来看看AppClassLoader的集成关系


在mac上按option+command+u查看集成关系图




 


 我们看到AppClassLoader继承自URLClassLoader,而URLClassLoader又继承了上面四个类,最终有继承一个叫做ClassLoader的类,所有的类加载器,最终都要继承这个ClassLoader类.


而这里调用的是super.loadClass(),我们来看看URLClassLoader中是否有loadClass()类,看过之后发现,他没有,最终这个super.loadClass()是继承了ClassLoader类的loadClass(....)方法




 


正是这个类实现了双亲委派机制,下面我们就来看看,他到底是怎么实现的?


当前的类加载器是AppClassLoader类加载器,首先第一步是查找AppClassLoader中已经加载的类中,有没有这个类,




 


 


 通过调用findLoadedClass(name)方法来查询已经加载的类中,有没有com.lxl.jvm.Math类. 那么findLoadedClass(name)里面做了什么呢? 我们进去看看


 


 


我们看到,findLoaderClass(name)方法调用了自己的一个方法findLoadedClass0,  这个方法是native的,也就是是本地方法,使用c++实现的,我们不能看到底部的具体实现细节了. 但是大致的逻辑就是在已经加载的类中查找有没有com.lxl.jvm.Math这个类,如果有就返回Class类信息.




 


 debug看到,显然是没有的,接下来就是走到if(c == null)里面了,这里做了什么事呢?




 


 他判断了,当前这个类加载器的parent是否是null. 我们知道当前这个类加载是AppClassLoader,他的parent是ExtClassLoader,自然不是null,就会执行里面的parent.loadClass(name,false);


也就是执行扩展类加载器的loadClass(...)方法. 我们来看看扩展类ExtClassLoader




 


我们发现ExtClassLoader类里面没有loadClass(...)方法,那他没有,肯定就是在父类里定义的了,通过查找,最后我们发现这个方法还是ClassLoader里的loadClass(...)方法. 于是,我们继续debug.肯定会再次走到loadClass(...)这个方法里来. 而此时,loadClass是ExtClassloader的loadClass(...)方法




 


 果然,又走到这个方法里面来了


继续往下执行,首先查找ExtClassLoader中已经加载的类中,是否有java.lxl.jvm.Math类,过程和上面是一样的. 最后调用的是本地方法. 


我们知道,这肯定是没有的了. 然后继续判断,ExtClassLoader的parent是否为空. 很显然,他就是空啊,因为ExtClassLoader的父类加载器是引导类加载器BootStrapClassLoader,而引导类加载器是c++写的,这里的parent为空. parent为空执行的是else中的代码




 


 这个方法就是去引导类加载器BootstrapClassLoad中查找,是否有这个类,我们来看看引导类加载器里面的具体实现




 


 我们发现,最后具体的逻辑也是一个本地方法实现的. 我们还是猜测一下,这就是去查找引导类加载器已经加载的类中有没有com.lxl.jvm.Math,如果有就返回这个类,如果没有就返回null.


很显然,是没有的. c == null. 我们继续来看下面的代码


 


到此为止,我们第一次向上查找的过程就完完事了. 用图表示就是这样




 


 首先有应用程序类加载器加载类,判断应用程序已加载的类中,结果是没有,没有则调用其父类加载器ExtClassLoader的loadClass()方法,去扩展类加载器中查找是否有这个类,也没有. 那么判断其父类是否为空,确实为空,则进入到引导类加载器中取查找是否有这个类,最后引导类加载器中也没有,返回null


 


下面来看看类加载器是如何向下委派的?


引导类加载器中也没有这个类,返回null,接下来调用findClass(name);查找ExtClassLoader中是否有com.lxl.jvm.Math,我们来看看具体的实现. 首先这是谁的方法呢?是ExtClassLoader的. 




 


进入到findClass(name)方法中,首先看看ExtClassLoader类中是否有这个方法,没有,这里调用的是父类UrlClassLoader中的findClass()方法




 


在findClass()里面,我们看到将路径中的.替换为/,并在后面增加了.class. 这是在干什么呢? 不就是将com.lxl.jvm.Math替换为com/lxl/jvm/Math.class么


然后去resource库中查找是否有这个路径. 没有就返回null,有就进入到defineClass()方法.


我们想一想,在ExtClassLoader类路径里面能找到这个类么?显然是找不到的,因为这个类使我们自己定义的. 


他们他一定执行return null.




 


 正如我们分析,debug到了return null; 这是执行的ExtClassLoader的findClass(). 返回null,回到AppClassLoader加载类里面




 


 c就是null,然后继续执行findClass(name),这是还是进入到了URLClassPath类的findClass(name)




 


 如上图,此时调用的是AppClassLoader的findClass(name),此时的resource还是空么?当然不是了,在target目录中就有Math.class类,找到了,接下来执行defineClass(name,res)


defindClass这个方法是干什么的呢? 这个方法就是加载类. 类已经找到了,接下来要做的就是将其加载进来了. 


这里执行的就是我们之前说的类加载的几个步骤,如下图红线圈出的部分.




 好了,具体的就不说了. 后面有时间在继续分析.


这就是双亲委派机制的源码. 


那么当下一次在遇到com.lxl.jvm.Math类的时候,我们在AppClassLoader中就已经有了,直接就返回了.


在来看一遍双亲委派机制的流程图




 


1.3 为什么要有双亲委派机制?




两个原因: 
1. 沙箱安全机制,自己写的java.lang.String.class类不会被加载,这样便可以防止核心API库被随意修改
2. 避免类重复加载. 比如之前说的,在AppClassLoader里面有java/jre/lib包下的类,他会加载么? 不会,他会让上面的类加载器加载,当上面的类加载器加载以后,就直接返回了,避免了重复加载.




 


我们来看下面的案例


加入,我在本地定义了一个String类,包名是java.lang.String. 也就是是rt.jar包下的String类的包名是一样的哈. 




 


 


 如上图,这是我们运行main方法,会怎么样? 没错,会报错




 


 


 下面分析一下,为什么会报错呢?


还是看双亲委派机制的流程,首先由AppClassLoader类加载器加载,看看已经加载的类中有没有java.lang.String这个类,我们发现,找ExtClassLoader加载,也没有,然后交给引导类BootStrapClassLoader加载,结果能不能找到呢? 当然可以了. 但是这个java.lang.String是rt.jar中的类,不是我们自定义的类,加载了rt.jar中的java.lang.String类以后,去找main 方法,没找到.....结果就跑出了找不到main方法异常. 


 


所以说,如果我们自己定义的时候,想要重新定义一个系统加载的类,比如String.class,可能么? 不可能,因为自己定义的类根本不会被加载


这就是双亲委派机制的第一个作用: 沙箱安全机制, 自己写的java.lang.String.class类不会被加载,这样便可以防止核心API库被随意修改


双亲委派机制还有一个好处: 避免类重复加载. 比如之前说的,避免了重复加载.


 
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。

                            

                    

                

                

                    

                        

                            
相关推荐

                            



                                
Java jinfo 命令详解

                                
jinfo 命令可以用来查看 Java 进程运行的 JVM 参数，命令如下：[root@admin ~]# jinfo --helpUsage:    jinfo [option] &lt;pid&gt;        (to connect to running process)    jinfo [option] &lt;executable &lt;core&gt;        (to connect to a core file)    jinfo [option] [serve

                            

                                
Java虚拟机栈

                                
原文链接：https://www.cnblogs.com/niejunlei/p/5987611.htmlJava Virtual Machine Stacks，线程私有，生命周期与线程相同，描述的是Java方法执行的内存模型：每一个方法执行的同时都会创建一个栈帧（Stack Frame），由于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法的执行就对应着栈帧在虚拟机栈中的入栈，出栈...

                            

                                
JVM 运行时内存使用情况监控

                                
java 语言, 开发者不能直接控制程序运行内存, 对象的创建都是由类加载器一步步解析, 执行与生成与内存区域中的; 并且jvm有自己的垃圾回收器对内存区域管理, 回收; 但是我们已经可以通过一些工具来在程序运行时查看对应的jvm内存使用情况, 帮助更好的分析与优化我们的代码;jps查看系统中有哪些java进程jps 命令类似与 linux 的 ps 命令，但是它只列出系统中所有的 Java 应用程序。 通过 jps 命令可以方便地查看 Java 进程的启动类、传入参数和 Java 虚拟机参数等信息

                            

                                
jvm

                                
1.jvm的简单抽象模型：  2.类加载机制     双亲委派模型是为了防止jdk核心类库被篡改，如果需要打破可以重写Classloader.loadClass方法。r 双亲委派模型：一个类加载器收到一个类的加载请求，他会先判断自身是否已存在该类，如果不存在上抛给上一级类加载器ClassLoad

                            

                                
堆外内存的回收机制分析

                                
堆外内存JVM启动时分配的内存，称为堆内存，与之相对的，在代码中还可以使用堆外内存，比如Netty，广泛使用了堆外内存，但是这部分的内存并不归JVM管理，GC算法并不会对它们进行回收，所以在使用堆外内存时，要格外小心，防止内存一直得不到释放，造成线上故障。堆外内存的申请和释放JDK的ByteBuffe

                            

                                
2022-08-16面试

                                
1.springboot和tomcat2.springcloud的请求如何通过网关鉴权？3.springmvc启动时组件的加载顺序？4.mybatis如何同时更新三条记录5.hibernate实现级联更新6.一个web程序应用程序启动时的加载流程7.如何向www.baidu.com地址发出请求时，并获取相应？8.？？？9.谈谈你对tcp/iptelnetudp协

                            

                                
JVM常用配置参数说明

                                
堆设置-Xms256M：初始堆大小256M，默认为物理内存的1/64-Xmx1024M：最大堆大小1024M，默认为物理内存的1/4，等于与-XX:MaxHeapSize=64M-Xmn64M：年轻代大小为64M（JDK1.4后支持），相当于同时设置NewSize和MaxNewSize为64M-XX:NewSize=64M：初始年轻代大小-XX:MaxNewSize=256M：最大年轻代大小（默认

                            

                                
关于JVM——垃圾收集器

                                
一.概述收集算法（JVM之垃圾回收-垃圾收集算法）是内存回收的抽象策略，垃圾收集器就是内存回收的具体实现。JVM规范对于垃圾收集器的应该如何实现没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器差别较大，这里只看HotSpot虚拟机。就像没有最好的算法一样，垃圾收集器

                            

                                
JVM学习八-复习年轻代、老年代、永久代

                                
Java中的堆是JVM所管理的最大的一块内存空间，主要用于存放各种类的实例对象，如下图所示： 在Java中，堆被划分成两个不同的区域：新生代(Young)、老年代(Old)。新生代(Young)又被划分为三个区域：Eden、S0、S1。 这样划分的目的是为了使JVM能够更好的管理堆内存中的对象，包

                            

                                
《深入理解JVM(4)——如何优化Java GC「译」》

                                
JVM深入理解JVM(4)——如何优化JavaGC「译」 PostedbyCrowonAugust21,2017本文翻译自SangminLee发表在Cubrid上的”BecomeaJavaGCExpert”系列文章的第三篇《HowtoTuneJavaGarbageCollection》,本文的作者是韩国人，写在JDK1.8发布之前，虽然有些地

                            

                                
《深入理解JVM(2)——GC算法与内存分配策略》

                                
 JVM深入理解JVM(2)——GC算法与内存分配策略 PostedbyCrowonAugust10,2017说起垃圾收集（GarbageCollection,GC），想必大家都不陌生，它是JVM实现里非常重要的一环，JVM成熟的内存动态分配与回收技术使Java（当然还有其他运行在JVM上的语言，如Scala等）程序员在提升开

                            

                                
JVM虚拟机------运行时数据区----总体概览

                                
运行时数据区  线程独有本地方法栈、虚拟机栈、程序计数器这些与线程对应的数据区会随着线程开始和结束创建和销毁  整体公有元数据区（又称方法区）、堆区会随着虚拟机启动而创建，随着虚拟机退出而销毁 

                            

                                
JVM参数

                                
java整个堆大小设置：Xmx和Xms设置为老年代存活对象的3-4倍，即FullGC之后的老年代内存占用的3-4倍。永久代PermSize和MaxPermSize设置为老年代存活对象的1.2-1.5倍年轻代Xmx的设置为老年代存活对象的1-1.5倍老年代的内存大小设置为老年代存活对象的2-3倍BTW： Sun官方建议年轻代

                            

                                
JVM虚拟机栈------运行时数据区-------栈顶缓存技术

                                
栈顶缓存（Top-of-StackCashing）技术基于栈式架构得虚拟机所使用的零地址指令更加紧凑，但完成一项操作的时候必然使用更多的入栈和出栈指令，这同时也就意味着将需要更多的指令分派次数和内存读写次数 由于操作数是存储在内存重的，因此频繁地执行内存读/写操作必然影响速度。 综上

                            

                                
jdk体系和jvm

                                
自用。同样的代码在不同的平台生成的机器码是不一样的，为什么java代码生成的字节码文件，能在不同的平台运行？因为不同版本的jdk里面的虚拟机会屏蔽不同操作系统在底层硬件与指令上的区别。栈：线程栈，局部变量存放栈内存区域。线程（分配一个栈）运行分配栈将局部变量放入内存。怎么放：栈

                            

                                
jvm 监控

                                
jconsole监控：1.java启动命令加上参数java-Djava.rmi.server.hostname=172.16.17.247-Dcom.sun.management.jmxremote-Dcom.sun.management.jmxremote.port=2099-Dcom.sun.management.jmxremote.authenticate=false-Dcom.sun.management.jmxremote.ssl=false -XX:+Unlock

                            

                                
JVM虚拟机------类加载器

                                
类加载器分类publicclassStackStruTest{publicstaticvoidmain(String[]args){//对用户自定义个类来说：默认使用系统类加载器进行加载-----AppClassLoaderClassLoaderclassLoader=StackStruTest.class.getClassLoader();System.out.p

                            

                                
【JVM】堆体系结构及其内存调优

                                
堆体系结构一个JVM实例只存在一个堆内存，堆内存的大小是可调节的。类加载器读取类文件后，需要把类、方法、常量、变量放在堆内存中，保存所有引用类型的真实信息，以方便执行器指向，堆内存分为三个部分：年轻代、老年代、永久代。Java7之前，堆内存在逻辑上分为：年轻代、老年代、永久代。物

                            

                                
《深入理解JVM(5)——虚拟机类加载机制》

                                
JVM深入理解JVM(5)——虚拟机类加载机制 PostedbyCrowonAugust21,2017在Class文件中描述的各种信息，最终都需要加载到虚拟机中之后才能运行和使用。而虚拟机中，而虚拟机如何加载这些Class文件？Class文件中的信息进入到虚拟机中会发生什么变化？本文将逐步解答这

                            

                                
JAVA基础java序列化，创建可复用的java对象

                                
保存(持久化)对象及其状态到内存或者磁盘Java平台允许我们在内存中创建可复用的Java对象，但一般情况下，只有当JVM处于运行时，这些对象才可能存在，即，这些对象的生命周期不会比JVM的生命周期更长。但在现实应用中，就可能要求在JVM停止运行之后能够保存(持久化)指定的对象，并在

                            

                    



            

            

              
          

            

              




              

            

          

          
          

            

              

                  
    
              

            

          

          

            

              

                  
    
              

            

          

          
          

            

              

                
                
pythonJavaScriptjavaHTMLPHPreactjsC#AndroidCSSNode.jssqlrpython-3.xMysqLjQueryc++pandasFlutterangularIOSdjangolinuxswifttypescript路由器JSON路由器设置无线路由器h3c华三华三路由器设置华三路由器电脑软件教程arraysdocker软件图文教程Cvue.jslaravelspring-boot