Java周边技术解析

代理

静态代理

/** 
 * 定义一个账户接口 
 *  
 * @author Administrator 
 *  
 */  
public interface Count {  
    // 查看账户方法  
    public void queryCount();  
  
    // 修改账户方法  
    public void updateCount();  
  
}

public class CountImpl implements Count {  
  
    @Override  
    public void queryCount() {  
        System.out.println("查看账户方法...");  
  
    }  
  
    @Override  
    public void updateCount() {  
        System.out.println("修改账户方法...");  
  
    }  
  
}  

public class CountProxy implements Count {  
    private CountImpl countImpl;  
  
    /** 
     * 覆盖默认构造器 
     *  
     * @param countImpl 
     */  
    public CountProxy(CountImpl countImpl) {  
        this.countImpl = countImpl;  
    }  
  
    @Override  
    public void queryCount() {  
        System.out.println("事务处理之前");  
        // 调用委托类的方法;  
        countImpl.queryCount();  
        System.out.println("事务处理之后");  
    }  
  
    @Override  
    public void updateCount() {  
        System.out.println("事务处理之前");  
        // 调用委托类的方法;  
        countImpl.updateCount();  
        System.out.println("事务处理之后");  
  
    }  
  
}

public class TestCount {  
    public static void main(String[] args) {  
        CountImpl countImpl = new CountImpl();  
        CountProxy countProxy = new CountProxy(countImpl);  
        countProxy.updateCount();  
        countProxy.queryCount();  
    }  
}

发现每一个代理类只能为一个接口服务，这样一来程序开发中必然会产生过多的代理

解决这一问题最好的做法是可以通过一个代理类完成全部的代理功能，那么此时就必须使用动态代理完成。

JDK动态代理

JDK动态代理中包含一个类和一个接口

InvocationHandler接口

public interface InvocationHandler { 
public Object invoke(Object proxy,Method method,Object[] args) throws Throwable; 
} 
参数说明： 
Object proxy：指被代理的对象。 
Method method：要调用的方法 
Object[] args：方法调用时所需要的参数

可以将InvocationHandler接口的子类想象成一个代理的最终操作类，替换掉ProxySubject。

Proxy类

Proxy类是专门完成代理的操作类，可以通过此类为一个或多个接口动态地生成实现类，此类提供了如下的操作方法：

public static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces, 
InvocationHandler h) 
throws IllegalArgumentException 
参数说明： 
ClassLoader loader：类加载器 
Class<?>[] interfaces：得到全部的接口 
InvocationHandler h：得到InvocationHandler接口的子类实例

在Proxy类中的newProxyInstance()方法中需要一个ClassLoader类的实例，ClassLoader实际上对应的是类加载器，在Java中主要有一下三种类加载器;

Booststrap ClassLoader：此加载器采用C++编写，一般开发中是看不到的；
Extendsion ClassLoader：用来进行扩展类的加载，一般对应的是jre\lib\ext目录中的类;
AppClassLoader：(默认)加载classpath指定的类，是最常使用的是一种加载器。

示例

public interface BookFacade {  
    public void addBook();  
}  


public class BookFacadeImpl implements BookFacade {  
  
    @Override  
    public void addBook() {  
        System.out.println("增加图书方法。。。");  
    }  
  
}


public class BookFacadeProxy implements InvocationHandler {  
    private Object target;  
    /** 
     * 绑定委托对象并返回一个代理类 
     * @param target 
     * @return 
     */  
    public Object bind(Object target) {  
        this.target = target;  
        //取得代理对象  
        return Proxy.newProxyInstance(target.getClass().getClassLoader(),  
                target.getClass().getInterfaces(), this);   //要绑定接口(这是一个缺陷，cglib弥补了这一缺陷)  
    }  
  
    @Override  
    /** 
     * 调用方法 
     */  
    public Object invoke(Object proxy, Method method, Object[] args)  
            throws Throwable {  
        Object result=null;  
        System.out.println("事物开始");  
        //执行方法  
        result=method.invoke(target, args);  
        System.out.println("事物结束");  
        return result;  
    }  
  
} 

public static void main(String[] args) {  
    BookFacadeProxy proxy = new BookFacadeProxy();  
    BookFacade bookProxy = (BookFacade) proxy.bind(new BookFacadeImpl());  
    bookProxy.addBook();  
}

CGlib动态代理

JDK的动态代理机制只能代理实现了接口的类，而不能实现接口的类就不能实现JDK的动态代理
cglib是针对类继承来实现代理的

他的原理是对指定的目标类生成一个子类，并覆盖其中方法实现增强，但因为采用的是继承，所以不能对final修饰的类进行代理。

示例

public class Base {  
    /** 
     * 一个模拟的add方法 
     */  
    public void add() {  
        System.out.println("add ------------");  
    }  
}  



public class CglibProxy implements MethodInterceptor {  
  
    public Object intercept(Object object, Method method, Object[] args,  
            MethodProxy proxy) throws Throwable {  
        // 添加切面逻辑（advise），此处是在目标类代码执行之前，即为MethodBeforeAdviceInterceptor。  
        System.out.println("before-------------");  
        // 执行目标类add方法  
        proxy.invokeSuper(object, args);  
        // 添加切面逻辑（advise），此处是在目标类代码执行之后，即为MethodAfterAdviceInterceptor。  
        System.out.println("after--------------");  
        return null;  
    }  
  
}


public class Factory {  
    /** 
     * 获得增强之后的目标类，即添加了切入逻辑advice之后的目标类 
     *  
     * @param proxy 
     * @return 
     */  
    public static Base getInstance(CglibProxy proxy) {  
        Enhancer enhancer = new Enhancer();  
        enhancer.setSuperclass(Base.class);  
        //回调方法的参数为代理类对象CglibProxy，最后增强目标类调用的是代理类对象CglibProxy中的intercept方法  
        enhancer.setCallback(proxy);  
        // 此刻，base不是单纯的目标类，而是增强过的目标类  
        Base base = (Base) enhancer.create();  
        return base;  
    }  
}  

public class Test {  
    public static void main(String[] args) {  
        CglibProxy proxy = new CglibProxy();  
        // base为生成的增强过的目标类  
        Base base = Factory.getInstance(proxy);  
        base.add();  
    }  
}

Aspectj

AspectJ 是最早、功能比较强大的 AOP 实现之一

Spring AOP相同点

Spring AOP 同样需要对目标类进行增强，也就是生成新的 AOP 代理类

Spring AOP不同点

与 AspectJ 不同的是，Spring AOP 无需使用任何特殊命令对 Java源代码进行编译
它采用运行时动态地、在内存中临时生成”代理类”的方式来生成 AOP 代理。

Spring 允许使用 AspectJ Annotation 用于定义方面(Aspect)、切入点(Pointcut)和增强处理(Advice)
Spring 框架则可识别并根据这些 Annotation 来生成 AOP 代理。
Spring 只是使用了和 AspectJ 5 一样的注解，但并没有使用 AspectJ 的编译器或者织入器(Weaver),底层依然使用的是 Spring AOP，依然是在运行时动态生成 AOP 代理，并不依赖于 AspectJ 的编译器或者织入器。

Aop 运行时生成代理方案选择

<aop:aspectj-autoproxy proxy-target-class="true">

//org.springframework.transaction.interceptor.TransactionProxyFactoryBean是org.springframework.aop.framework. ProxyConfig的子类
//所以可以参照ProxyConfig里的一些设置如下所示，将optimize和proxyTargetClass任意一个设置为true都可以强制Spring采用CGLIB代理。

proxy-target-class属性设为true:强制使用CGLIB代理;

JDK动态代理:其代理对象必须是某个接口的实现，它是通过在运行期间创建一个接口的实现类来完成对目标对象的代理。

CGLIB代理:实现原理类似于JDK动态代理，只是它在运行期间生成的代理对象是针对目标类扩展的子类。CGLIB是高效的代码生成包，底层是依靠ASM（开源的java字节码编辑类库）操作字节码实现的，性能比JDK强。

public AopProxy createAopProxy(AdvisedSupport advisedSupport) throws AopConfigException {   

    //在此判断使用JDK动态代理还是CGLIB代理   

    if (advisedSupport.isOptimize() || advisedSupport.isProxyTargetClass()   

            || hasNoUserSuppliedProxyInterfaces(advisedSupport)) {   

        if (!cglibAvailable) {   
            throw new AopConfigException(   

                    "Cannot proxy target class because CGLIB2 is not available. "  

                            + "Add CGLIB to the class path or specify proxy interfaces.");   

        }   
        return CglibProxyFactory.createCglibProxy(advisedSupport);   
    } else {   
        return new JdkDynamicAopProxy(advisedSupport);   

    }   

}

advisedSupport.isOptimize()与advisedSupport.isProxyTargetClass()默认返回都是false,所以在默认情况下目标对象有没有实现接口决定着Spring采取的策略
当然可以设置advisedSupport.isOptimize()或者advisedSupport.isProxyTargetClass()返回为true,这样无论目标对象有没有实现接口Spring都会选择使用CGLIB代理。

所以在默认情况下,如果一个目标对象如果实现了接口Spring则会选择JDK动态代理策略动态的创建一个接口实现类(动态代理类)来代理目标对象,可以通俗的理解这个动态代理类是目标对象的另外一个版本,所以这两者之间在强制转换的时候会抛出java.lang.ClassCastException。
如果目标对象没有实现任何接口,Spring会选择CGLIB代理,其生成的动态代理对象是目标类的子类。

类加载

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段

图解分析类加载

public class ClassLoaderProduce {
    static int d=3;
    static{
        System.out.println("我是ClassLoaderProduce类");
    }
    public static void main(String [] args){
        int b=0;
        String c="hello";
        SimpleClass simpleClass=new SimpleClass();
        simpleClass.run();
    }
}

class SimpleClass{
    static int  a=3;
    static{
        a=100;
        System.out.println(a);
    }

    public SimpleClass(){
        System.out.println("对类进行加载！");
    }

    public void run(){
        System.out.println("我要跑跑跑！");
    }
}

相关解释

步骤一：装载ClassLoaderProduce类，在方法区生成动态数据结构(静态变量、静态方法、常量池、类代码)，并且在堆中生成java.lang.Class对象；然后进行链接

步骤二：初始化：把static{}与静态变量合并存放在类构造器当中，对静态变量赋值。 1-5行执行完毕。

步骤三：执行main方法，首先在栈里面生成一个main方法的栈祯，定义变量b、c，注意此处的变量b、c存储的常量池存储的变量的地址，如图所示。

步骤四：创建SimpleClass对象；跟上面步骤类似：加载-链接-初始化。然后，调用run()方法的时候，它会通过classLoader局部变量的地址寻找到类的class对象并且调用run()方法

加载

通过一个类的全限定名来获取其定义的二进制字节流。
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。

类加载器

启动类加载器：Bootstrap ClassLoader,跟上面相同。它负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下,或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。使用C++实现（这里仅限于Hotspot，也就是JDK1.5之后默认的虚拟机，有很多其他的虚拟机是用Java语言实现的）
扩展类加载器：Extension ClassLoader,该加载器由sun.misc.Launcher$ExtClassLoader实现,它负责加载JDK\jre\lib\ext目录中,或者由java.ext.dirs系统变量指定的路径中的所有类库(如javax.*开头的类),开发者可以直接使用扩展类加载器。
应用程序类加载器：Application ClassLoader,该类加载器由sun.misc.Launcher$AppClassLoader来实现,它负责加载用户类路径（ClassPath）所指定的类,开发者可以直接使用该类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

如果有必要，我们还可以加入自定义的类加载器。因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，因此如果编写了自己的ClassLoader，便可以做到如下几点：

1: 在执行非置信代码之前，自动验证数字签名。

2: 动态地创建符合用户特定需要的定制化构建类。

3: 从特定的场所取得java class，例如数据库中和网络中。

双亲委派模型

这种层次关系称为类加载器的双亲委派模型。我们把每一层上面的类加载器叫做当前层类加载器的父加载器
当然它们之间的父子关系并不是通过继承关系来实现的,而是使用组合关系来复用父加载器中的代码。
该模型在JDK1.2期间被引入并广泛应用于之后几乎所有的Java程序中,但它并不是一个强制性的约束模型,而是Java设计者们推荐给开发者的一种类的加载器实现方式。

自己写的classloader:

首先执行loadclass函数,在这个函数里会执行findloadclass从缓存中找是否加载过这个类,如果没有直接调用父类的loadclass,先不找等父级找不到再找findclass,找到则返回

app class loader

首先执行loadclass函数,在这个函数里会执行findloadclass从缓存中找是否加载过这个类,如果没有直接调用父类的loadclass,先不找等父级找不到再找findclass,找到则返回

CLASS_PATH中找

ext class loader

首先执行loadclass函数,在这个函数里会执行findloadclass从缓存中找是否加载过这个类,如果没有直接调用父类的loadclass,先不找等父级找不到再找findclass,找到则返回

/JAVA_HOME/jre/lib/ext  中找

boot strap class loader

首先执行loadclass函数,在这个函数里会执行findloadclass从缓存中找是否加载过这个类,

/JAVA_HOME/jre/lib/ 中找

如果findclass找到则返回,如果没有则一层层通知下级再去找

工作流程

1: 如果一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类,而是把请求委托给父加载器去完成,依次向上
2: 因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中
3: 只有当父加载器在它的搜索范围中没有找到所需的类时,即无法完成该加载,子加载器才会尝试自己去加载该类。

优点

Java类随着它的类加载器(说白了,就是它所在的目录)一起具备了一种带有优先级的层次关系,这对于保证Java程序的稳定运作很重要。
例如，类java.lang.Object类存放在JDK\jre\lib下的rt.jar之中
因此无论是哪个类加载器要加载此类,最终都会委派给启动类加载器进行加载，
这边保证了Object类在程序中的各种类加载器中都是同一个类。

验证

为了确保Class文件中的字节流包含的信息符合当前虚拟机的要求
大致都会完成以下四个阶段的验证：文件格式的验证、元数据的验证、字节码验证和符号引用验证

文件格式的验证

验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。

元数据验证

对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。

字节码验证

该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。

符号引用验证

这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些内存都将在方法区中分配

1: 这时候进行内存分配的仅包括类变量(static),而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。

2: 这里所设置的初始值通常情况下是数据类型默认的零值(如0、0L、null、false等),而不是被在Java代码中被显式地赋予的值。
假设一个类变量的定义为:

1 2	public static int value = 3；

那么变量value在准备阶段过后的初始值为0,而不是3
因为这时候尚未开始执行任何Java方法,而把value赋值为3的putstatic指令是在程序编译后,存放于类构造器()方法之中的
所以把value赋值为3的动作将在初始化阶段才会执行。

解析

解析阶段是虚拟机将常量池中的符号引用转化为直接引用的过程。

符号引用：符号引用以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标并不一定已经加载到了内存中。
直接引用：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那说明引用的目标必定已经存在于内存之中了。

解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行
分别对应于常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四种常量类型。

类或接口的解析

判断所要转化成的直接引用是对数组类型,还是普通的对象类型的引用,从而进行不同的解析。

字段解析

对字段进行解析时,会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段
如果有,则查找结束;
如果没有,则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口,还没有,则按照继承关系从上往下递归搜索其父类,直至查找结束,查找流程如下图

class Super{  
    public static int m = 11;  
    static{  
        System.out.println("执行了super类静态语句块");  
    }  
}  
  
  
class Father extends Super{  
    public static int m = 33;  
    static{  
        System.out.println("执行了父类静态语句块");  
    }  
}  
  
class Child extends Father{  
    static{  
        System.out.println("执行了子类静态语句块");  
    }  
}  
  
public class StaticTest{  
    public static void main(String[] args){  
        System.out.println(Child.m);  
    }  
}  


//执行了super类静态语句块
//执行了父类静态语句块
//33

类方法解析

对类方法的解析与对字段解析的搜索步骤差不多,只是多了判断该方法所处的是类还是接口的步骤,而且对类方法的匹配搜索,是先搜索父类,再搜索接口。

接口方法解析

与类方法解析步骤类似,只是接口不会有父类,因此只递归向上搜索父接口就行了。

初始化

初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的Java程序代码。

准备阶段,类变量已经被赋过一次系统要求的初始值
初始化阶段,则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源,或者可以从另一个角度来表达:初始化阶段是执行类构造器()方法的过程。

clinit() 收集产生

clinit()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的
编译器收集的顺序是由语句在源文件中出现的顺序所决定的
静态语句块中只能访问到定义在静态语句块之前的变量
定义在它之后的变量,在前面的静态语句中可以赋值,但是不能访问。

class Father{
    static{
        System.out.println(a);  //不可以,必须当public static int a = 1;在前方位置
        a = 2;
    }
    public static int a = 1;
}

clinit() 的产生规则

clinit()方法对于类或接口来说并不是必须的,如果一个类中没有静态语句块,也没有对类变量的赋值操作,那么编译器可以不为这个类生成clinit()方法。

类的执行顺序 clinit()

clinit()方法与实例构造器clinit()方法(类的构造函数)不同,它不需要显式地调用父类构造器,虚拟机会保证在子类的clinit()方法执行之前,父类的clinit()方法已经执行完毕。
因此,在虚拟机中第一个被执行的clinit()方法的类肯定是java.lang.Object。

接口与类的不同 clinit()

接口中不能使用静态语句块，但仍然有类变量(final static)初始化的赋值操作，因此接口与类一样会生成clinit()方法。
但是接口与类不同的是:执行接口的clinit()方法不需要先执行父接口的clinit()方法,只有当父接口中定义的变量被使用时,父接口才会被初始化。
另外,接口的实现类在初始化时也一样不会执行接口的clinit()方法。

clinit() 的加锁

虚拟机会保证一个类clinit()方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的clinit()方法，其他线程都需要阻塞等待，直到活动线程执行clinit()方法完毕。
如果在一个类的clinit()方法中有耗时很长的操作，那就可能造成多个线程阻塞，在实际应用中这种阻塞往往是很隐蔽的。

参考

-JVM 类加载