一、什么是代理？
代理是一种常用的设计模式，其目的就是为其他对象提供一个代理以控制对某个对象的访问。代理类负责为委托类预处理消息，过滤消息并转发消息，以及进行消息被委托类执行后的后续处理。
代理模式UML图：
为了保持行为的一致性，代理类和委托类通常会实现相同的接口，所以在访问者看来两者没有丝毫的区别。通过代理类这中间一层，能有效控制对委托类对象的直接访问，也可以很好地隐藏和保护委托类对象，同时也为实施不同控制策略预留了空间，从而在设计上获得了更大的灵活性。Java 动态代理机制以巧妙的方式近乎完美地实践了代理模式的设计理念。
二、Java 动态代理类
Java动态代理类位于java.lang.reflect包下，一般主要涉及到以下两个类：
(1)Interface InvocationHandler：该接口中仅定义了一个方法
- publicobject invoke(Object obj,Method method, Object[] args)
在实际使用时，第一个参数obj一般是指代理类，method是被代理的方法，如上例中的request()，args为该方法的参数数组。这个抽象方法在代理类中动态实现。
(2)Proxy：该类即为动态代理类，其中主要包含以下内容：
protected Proxy(InvocationHandler h)：构造函数，用于给内部的h赋值。
static Class getProxyClass (ClassLoaderloader, Class[] interfaces)：获得一个代理类，其中loader是类装载器，interfaces是真实类所拥有的全部接口的数组。
static Object newProxyInstance(ClassLoaderloader, Class[] interfaces, InvocationHandler h)：返回代理类的一个实例，返回后的代理类可以当作被代理类使用(可使用被代理类的在Subject接口中声明过的方法)
所谓DynamicProxy是这样一种class：它是在运行时生成的class，在生成它时你必须提供一组interface给它，然后该class就宣称它实现了这些interface。你当然可以把该class的实例当作这些interface中的任何一个来用。当然，这个DynamicProxy其实就是一个Proxy，它不会替你作实质性的工作，在生成它的实例时你必须提供一个handler，由它接管实际的工作。
在使用动态代理类时，我们必须实现InvocationHandler接口
通过这种方式，被代理的对象(RealSubject)可以在运行时动态改变，需要控制的接口(Subject接口)可以在运行时改变，控制的方式(DynamicSubject类)也可以动态改变，从而实现了非常灵活的动态代理关系。
动态代理步骤：
1.创建一个实现接口InvocationHandler的类，它必须实现invoke方法
2.创建被代理的类以及接口
3.通过Proxy的静态方法
newProxyInstance(ClassLoaderloader, Class[] interfaces, InvocationHandler h)创建一个代理
4.通过代理调用方法
三、JDK的动态代理怎么使用？
1、需要动态代理的接口：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
;
/**
* 需要动态代理的接口
*/
Subject
{
/**
* 你好
*
* @param name
* @return
*/
;
/**
* 再见
*
* @return
*/
;
}
|
2、需要代理的实际对象
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
;
/**
* 实际对象
*/
Subject
{
/**
* 你好
*
* @param name
* @return
*/
)
{
;
}
/**
* 再见
*
* @return
*/
)
{
;
}
}
|
3、调用处理器实现类
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
|
;
;
;
/**
* 调用处理器实现类
* 每次生成动态代理类对象时都需要指定一个实现了该接口的调用处理器对象
*/
InvocationHandler
{
/**
* 这个就是我们要代理的真实对象
*/
;
/**
* 构造方法，给我们要代理的真实对象赋初值
*
* @param subject
*/
)
{
;
}
/**
* 该方法负责集中处理动态代理类上的所有方法调用。
* 调用处理器根据这三个参数进行预处理或分派到委托类实例上反射执行
*
* @param proxy 代理类实例
* @param method 被调用的方法对象
* @param args 调用参数
* @return
* @throws Throwable
*/
Throwable
{
//在代理真实对象前我们可以添加一些自己的操作
;
;
//当代理对象调用真实对象的方法时，其会自动的跳转到代理对象关联的handler对象的invoke方法来进行调用
;
//在代理真实对象后我们也可以添加一些自己的操作
;
;
}
}
|
4、测试
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
;
;
;
/**
* 动态代理演示
*/
DynamicProxyDemonstration
{
)
{
//代理的真实对象
;
/**
* InvocationHandlerImpl 实现了 InvocationHandler 接口，并能实现方法调用从代理类到委托类的分派转发
* 其内部通常包含指向委托类实例的引用，用于真正执行分派转发过来的方法调用.
* 即：要代理哪个真实对象，就将该对象传进去，最后是通过该真实对象来调用其方法
*/
;
;
;
/**
* 该方法用于为指定类装载器、一组接口及调用处理器生成动态代理类实例
*/
;
;
;
;
// String goodbye = subject.SayGoodBye();
// System.out.println(goodbye);
}
}
|
5、输出结果如下：
演示demo下载地址：http://download.csdn.net/detail/xunzaosiyecao/9597388
四、动态代理怎么实现的？
从使用代码中可以看出，关键点在：
|
1
|
;
|
通过跟踪提示代码可以看出：当代理对象调用真实对象的方法时，其会自动的跳转到代理对象关联的handler对象的invoke方法来进行调用。
也就是说，当代码执行到：
subject.SayHello(“jiankunking”)这句话时，会自动调用InvocationHandlerImpl的invoke方法。这是为啥呢？
======横线之间的是代码跟分析的过程，不想看的朋友可以直接看结论======
以下代码来自:JDK1.8.0_92
既然生成代理对象是用的Proxy类的静态方newProxyInstance，那么我们就去它的源码里看一下它到底都做了些什么？
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
,
,
)
IllegalArgumentException
{
//检查h 不为空，否则抛异常
;
;
;
{
;
}
/*
* 获得与指定类装载器和一组接口相关的代理类类型对象
*/
;
/*
* 通过反射获取构造函数对象并生成代理类实例
*/
{
{
;
}
//获取代理对象的构造方法（也就是$Proxy0(InvocationHandler h)）
;
;
{
{
{
;
;
}
;
}
//生成代理类的实例并把InvocationHandlerImpl的实例传给它的构造方法
;
{
;
{
;
{
;
{
;
}
{
;
}
}
|
我们再进去getProxyClass0方法看一下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
/**
* Generate a proxy class. Must call the checkProxyAccess method
* to perform permission checks before calling this.
*/
,
{
{
;
}
// If the proxy class defined by the given loader implementing
// the given interfaces exists, this will simply return the cached copy;
// otherwise, it will create the proxy class via the ProxyClassFactory
;
}
|
真相还是没有来到，继续，看一下proxyClassCache
|
1
2
3
4
5
|
/**
* a cache of proxy classes
*/
>>
;
|
奥，原来用了一下缓存啊
那么它对应的get方法啥样呢？
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
/**
* Look-up the value through the cache. This always evaluates the
* {code subKeyFactory} function and optionally evaluates
* {code valueFactory} function if there is no entry in the cache for given
* pair of (key, subKey) or the entry has already been cleared.
*
* @param key possibly null key
* @param parameter parameter used together with key to create sub-key and
* value (should not be null)
* @return the cached value (never null)
* @throws NullPointerException if {code parameter} passed in or
* {code sub-key} calculated by
* {code subKeyFactory} or {code value}
* calculated by {code valueFactory} is null.
*/
{
;
;
;
// lazily install the 2nd level valuesMap for the particular cacheKey
;
{
//putIfAbsent这个方法在key不存在的时候加入一个值,如果key存在就不放入
oldValuesMap
,
;
{
;
}
}
// create subKey and retrieve the possible Supplier stored by that
// subKey from valuesMap
;
;
;
{
{
// supplier might be a Factory or a CacheValue instance
;
{
;
}
}
// else no supplier in cache
// or a supplier that returned null (could be a cleared CacheValue
// or a Factory that wasn't successful in installing the CacheValue)
// lazily construct a Factory
{
;
}
{
;
{
// successfully installed Factory
;
}
// else retry with winning supplier
{
{
// successfully replaced
// cleared CacheEntry / unsuccessful Factory
// with our Factory
;
{
// retry with current supplier
;
}
}
}
}
|
我们可以看到它调用了 supplier.get(); 获取动态代理类，其中supplier是Factory,这个类定义在WeakCach的内部。
来瞅瞅，get里面又做了什么？
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
// serialize access
// re-check
;
{
// something changed while we were waiting:
// might be that we were replaced by a CacheValue
// or were removed because of failure ->
// return null to signal WeakCache.get() to retry
// the loop
;
}
// else still us (supplier == this)
// create new value
;
{
;
{
// remove us on failure
;
}
}
// the only path to reach here is with non-null value
;
// wrap value with CacheValue (WeakReference)
;
// try replacing us with CacheValue (this should always succeed)
{
// put also in reverseMap
;
{
;
}
// successfully replaced us with new CacheValue -> return the value
// wrapped by it
;
}
}
|
发现重点还是木有出现，但我们可以看到它调用了valueFactory.apply(key, parameter)方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
/**
* A factory function that generates, defines and returns the proxy class given
* the ClassLoader and array of interfaces.
*/
ProxyClassFactory
>>
{
// prefix for all proxy class names
;
// next number to use for generation of unique proxy class names
;
@Override
{
;
{
/*
* Verify that the class loader resolves the name of this
* interface to the same Class object.
*/
;
{
;
{
}
{
(
;
}
/*
* Verify that the Class object actually represents an
* interface.
*/
{
(
;
}
/*
* Verify that this interface is not a duplicate.
*/
{
(
;
}
}
// package to define proxy class in
;
/*
* Record the package of a non-public proxy interface so that the
* proxy class will be defined in the same package. Verify that
* all non-public proxy interfaces are in the same package.
*/
{
;
{
;
;
;
;
{
;
{
(
;
}
}
}
{
// if no non-public proxy interfaces, use com.sun.proxy package
;
}
/*
* Choose a name for the proxy class to generate.
*/
;
;
/*
* Generate the specified proxy class.
*/
(
;
{
,
;
{
/*
* A ClassFormatError here means that (barring bugs in the
* proxy class generation code) there was some other
* invalid aspect of the arguments supplied to the proxy
* class creation (such as virtual machine limitations
* exceeded).
*/
;
}
}
}
|
通过看代码终于找到了重点：
|
1
2
|
//生成字节码
;
|
那么接下来我们也使用测试一下，使用这个方法生成的字节码是个什么样子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
;
;
;
;
;
;
;
;
/**
* 动态代理演示
*/
DynamicProxyDemonstration
{
)
{
//代理的真实对象
;
/**
* InvocationHandlerImpl 实现了 InvocationHandler 接口，并能实现方法调用从代理类到委托类的分派转发
* 其内部通常包含指向委托类实例的引用，用于真正执行分派转发过来的方法调用.
* 即：要代理哪个真实对象，就将该对象传进去，最后是通过该真实对象来调用其方法
*/
;
;
;
/**
* 该方法用于为指定类装载器、一组接口及调用处理器生成动态代理类实例
*/
;
;
;
;
// 将生成的字节码保存到本地，
;
}
{
;
;
;
{
;
;
;
{
;
{
;
{
{
;
{
;
}
}
}
}
|
我们用jd-jui 工具将生成的字节码反编译：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
;
;
;
;
;
ProxySubject
Proxy
Subject
{
;
;
;
;
;
)
{
;
}
)
{
try
{
;
}
)
{
;
}
)
{
;
}
}
)
{
try
{
;
}
)
{
;
}
)
{
;
}
}
)
{
try
{
;
}
)
{
;
}
)
{
;
}
}
)
{
try
{
;
}
)
{
;
}
)
{
;
}
}
)
{
try
{
;
}
)
{
;
}
)
{
;
}
}
static
{
try
{
;
;
;
;
;
;
}
)
{
;
}
)
{
;
}
}
}
|
这就是最终真正的代理类，它继承自Proxy并实现了我们定义的Subject接口
也就是说：
|
1
|
;
|
这里的subject实际是这个类的一个实例，那么我们调用它的：
|
1
|
)
|
就是调用我们定义的InvocationHandlerImpl的 invoke方法：
======横线之间的是代码跟分析的过程，不想看的朋友可以直接看结论=======
五、结论
到了这里，终于解答了：
subject.SayHello(“jiankunking”)这句话时，为什么会自动调用InvocationHandlerImpl的invoke方法？
因为JDK生成的最终真正的代理类，它继承自Proxy并实现了我们定义的Subject接口，在实现Subject接口方法的内部，通过反射调用了InvocationHandlerImpl的invoke方法。
包含生成本地class文件的demo：http://download.csdn.net/detail/xunzaosiyecao/9597474
通过分析代码可以看出Java 动态代理，具体有如下四步骤：
- 通过实现 InvocationHandler 接口创建自己的调用处理器；
- 通过为 Proxy 类指定 ClassLoader 对象和一组 interface 来创建动态代理类；
- 通过反射机制获得动态代理类的构造函数，其唯一参数类型是调用处理器接口类型；
- 通过构造函数创建动态代理类实例，构造时调用处理器对象作为参数被传入。