⑧. 判定一个常量是否"废弃”还是相对简单,而要判定一个类型是否属于"不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件
①. 该类所有的实例都已经被回收。也就是Java堆中不存在该类及其任何派生子类的实例
②. 加载该类的类加载器已经被回收。这个条件除非是精心设计的可替换类加载器的场景。如JSP重加载等。否则通常是很难达成的
③. 该类对应的Java.lang.Class对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法
⑨. 说说类的加载器分类？
①. JVM支持两种类型的类加载器,分别为引导类加载器(Bootstrap ClassLoader)和自定义类加载器(User-Defined ClassLoader)
②. 从概念上来讲,自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器,但是Java虚拟机规范并没有这么定义,而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器
⑩. 说说你对引导类加载器、扩展类加载器和应用程序类加载器的理解
①. 引导类加载器
这个类加载使用C/C++语言实现的,嵌套在JVM内部
它用来加载Java的核心类库(JAVA_HOME/jre/lib/rt.jar、resource.jar或sum.boot.class.path路径下的内容),用于提供JVM自身需要的类(String类就是使用的这个类加载器)
由于安全考虑,Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类
不继承自java.lang.ClassLoader,没有父加载器
②. 扩展类加载器 Extension
Java语言编写,由sum.music.Launcher$ExtClassLoader实现
派生于ClassLoader类,父类加载器为启动类加载器
从java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/lib/ext子目录(扩展目录)下加载类库。如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载
③. 系统类加载器(Application)
Java语言编写,由sum.music.Launcher$AppClassLoader实现
派生于ClassLoader类,父类加载器为扩展类加载器
它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
调用System.getSystemClassLoader() |
Thread.currentThread().getContextClassLoader()获取到的是系统类加载器
⑩①. 谈谈你对双亲委派机制的理解
①. 如果一个类加载收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类加载器去执行
②. 如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器
③. 如果父类的加载器可以完成类的加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式
