类加载器和代理

左大括号是否要另起一行：

公司会用类似于checklist的模版来约束你怎么样放置左括号的位置.

但没啥区别,重要的是程序的逻辑清晰，注释多些即可.

类加载器

Java虚拟机中可以安装多个类加载器，系统默认三个主要类加载器

每个类负责加载特定位置的类：BootStrap,ExtClassLoader,AppClassLoader

类加载器也是Java类，故类加载器本身也要需要被加载的

显然必有第一个类加载器不是java类，这正是BootStrap.

 

虚拟机要加载一个类时，到底派哪个类加载器呢？

首先当前线程的类加载器去加载线程中的第一个类.

如果类A中引用了类B，Java虚拟机将使用加载类A的类装载器来加载类B.
还可直接调用ClassLoader.loadClass()方法来指定某个类加载器去加载某个类.

 

每个类加载器加载类时，又先委托给其上级类加载器。

当所有祖宗类加载器没有加载到类,回到发起者类加载器,还加载不了,则抛ClassNotFoundException

不是再去找发起者类加载器的儿子,因为没有getChild方法,即使有,若有多个儿子,用哪一个呢？

 

类加载器的委托模式:类装载器逐级委托到BootStrap类加载器(先委托,不加载)

当委托到BootStrap,其无法加载当前所要加载的类时,然后才一级级回退到子孙类装载器去真正的加载

当回退到最初的类装载器时,若它自己也不能完成类的装载,就报ClassNotFoundException异常

BootStrap会很累,每次都要委托到它这里.但是这样有一个好处:

若有多个加载器,都能加载一个类,内存就会出现过两个相同的字节码.

而实现都交给BootStrap,逐级向下找就会避免加载器各干各的,可能出现重复的错误.

 

面试:能不能自己写个类叫java.lang.System

通常是不可以的.因为委托机制每次都先从BootStrap开始找.BootStrap中的rt.jar含有java.lang.Sysytem.直接加载,所以永远不会加载到自定义的System类

委托机制保证爸爸们优先,也就是总是使用爸爸们能找到的类，这样总是使用java系统提供的System.

当然可以自定义一个类加载器,跳出委托机制,不委托给继承树(具体做很高深的).

 

自定义类加载器

自定义的类加载器的必须继承ClassLoader

 

模板方法设计模式

父类-->loadClass

子类1： 子类2：

子类1,2都有loadClass的流程模式，但在执行时却要自己独特的代码.

就把共同的流程模式放在父类中,子类继承父类,子类的独特代码在父类中设成抽象方法即可.

总体流程在父类中已经规定好了,流程中的一些细节无法确定,就定义成抽象,子类自己完成

cypher v.翻译,加密

视频：0146,0147没看

一个类加载器的高级问题分析

java虚拟机中有很多类加载器，其中大部分是Tomcat项目自己开发的

在Tomcat下主要开发Servlet,Servlet也是java类，是被Tomcat提供的加载器加载的

通过Myeclipse创建web工程，创建一个类（较特殊），可以放在Tomcat中运行，该类父类是Servlet

Myeclipse中直接由new--->Servlet选项

 

代理

生活中的代理:

武汉人从武汉的代理商手中买联想电脑和直接跑到北京联想总部买电脑

目标基本上一样吧,都解决了核心问题—买了电脑

代理的好处:虽然你会多花点钱，但是总比你自己花路费来北京便宜.

程序中的代理:

一个类已经写好了.但是要为它增加点功能,例如:异常处理,日志等.你准备如何做？(该类的源代码你不知道)

 

采用工厂模式和配置文件方式进行管理,则不需要修改客户端程序 (因为引用接口)

在配置文件中配置是使用目标类还是代理类,这样以后很容易切换

譬如:

想要日志功能时就配置代理类,不适用就配置原来的目标类

这样增加系统功能很容易，要想去掉系统功能也很容易

[实例:程序开发出来,进行测试,监控运行时间,这时就要用代理监控,到发布时就不需要监控了,把配置文件改成调用目标而不是调用代理]

 

AOP Aspect Oriented Programming面向切面编程

 

代理类的各个方法中通常除了要调用目标的相应方法和对外返回目标返回的结果外，还可以在代理方法中的如下四个位置加上系统功能代码：

1.在调用目标方法之前

2.在调用目标方法之后

3.在调用目标方法前后

4.在处理目标方法异常的catch块中

 

分析JVM动态生成的类

创建动态类首先要有个接口