代理模式,即Proxy,它和Adapter模式很类似。我们先回顾Adapter模式,它用于把A接口转换为B接口:

    而Proxy模式不是把A接口转换成B接口,它还是转换成A接口:

    1. private A a;
    2. public AProxy(A a) {
    3. this.a = a;
    4. }
    5. public void a() {
    6. this.a.a();
    7. }
    8. }

    合着Proxy就是为了给A接口再包一层,这不是脱了裤子放屁吗?

    当然不是。我们观察Proxy的实现A接口的方法:

    1. public void a() {
    2. this.a.a();
    3. }

    这样写当然没啥卵用。但是,如果我们在调用a.a()的前后,加一些额外的代码:

    1. public void a() {
    2. if (getCurrentUser().isRoot()) {
    3. this.a.a();
    4. } else {
    5. throw new SecurityException("Forbidden");
    6. }
    7. }

    这样一来,我们就实现了权限检查,只有符合要求的用户,才会真正调用目标方法,否则,会直接抛出异常。

    有的童鞋会问,为啥不把权限检查的功能直接写到目标实例A的内部?

    因为我们编写代码的原则有:

    • 职责清晰:一个类只负责一件事;
    • 易于测试:一次只测一个功能。

    用Proxy实现这个权限检查,我们可以获得更清晰、更简洁的代码:

    • A接口:只定义接口;
    • ABusiness类:只实现A接口的业务逻辑;
    • APermissionProxy类:只实现A接口的权限检查代理。

    如果我们希望编写其他类型的代理,可以继续增加类似ALogProxy,而不必对现有的A接口、ABusiness类进行修改。

    实际上权限检查只是代理模式的一种应用。Proxy还广泛应用在:

    虚代理

    虚代理即Virtual Proxy,它让调用者先持有一个代理对象,但真正的对象尚未创建。如果没有必要,这个真正的对象是不会被创建的,直到客户端需要真的必须调用时,才创建真正的对象。JDBC的连接池返回的JDBC连接(Connection对象)就可以是一个虚代理,即获取连接时根本没有任何实际的数据库连接,直到第一次执行JDBC查询或更新操作时,才真正创建实际的JDBC连接。

    保护代理即Protection Proxy,它用代理对象控制对原始对象的访问,常用于鉴权。

    智能引用

    智能引用即Smart Reference,它也是一种代理对象,如果有很多客户端对它进行访问,通过内部的计数器可以在外部调用者都不使用后自动释放它。

    我们来看一下如何应用代理模式编写一个JDBC连接池(DataSource)。我们首先来编写一个虚代理,即如果调用者获取到Connection后,并没有执行任何SQL操作,那么这个Connection Proxy实际上并不会真正打开JDBC连接。调用者代码如下:

    现在我们来思考如何实现这个LazyConnectionProxy。为了简化代码,我们首先针对Connection接口做一个抽象的代理类:

    1. public abstract class AbstractConnectionProxy implements Connection {
    2. // 抽象方法获取实际的Connection:
    3. protected abstract Connection getRealConnection();
    4. // 实现Connection接口的每一个方法:
    5. public Statement createStatement() throws SQLException {
    6. return getRealConnection().createStatement();
    7. }
    8. public PreparedStatement prepareStatement(String sql) throws SQLException {
    9. return getRealConnection().prepareStatement(sql);
    10. }
    11. ...其他代理方法...
    12. }

    这个AbstractConnectionProxy代理类的作用是把Connection接口定义的方法全部实现一遍,因为Connection接口定义的方法太多了,后面我们要编写的LazyConnectionProxy只需要继承AbstractConnectionProxy,就不必再把Connection接口方法挨个实现一遍。

    LazyConnectionProxy实现如下:

    1. public class LazyConnectionProxy extends AbstractConnectionProxy {
    2. private Supplier<Connection> supplier;
    3. private Connection target = null;
    4. public LazyConnectionProxy(Supplier<Connection> supplier) {
    5. }
    6. // 覆写close方法:只有target不为null时才需要关闭:
    7. public void close() throws SQLException {
    8. if (target != null) {
    9. super.close();
    10. }
    11. }
    12. @Override
    13. protected Connection getRealConnection() {
    14. if (target == null) {
    15. target = supplier.get();
    16. }
    17. return target;
    18. }
    19. }

    如果调用者没有执行任何SQL语句,那么target字段始终为null。只有第一次执行SQL语句时(即调用任何类似prepareStatement()方法时,触发getRealConnection()调用),才会真正打开实际的JDBC Connection。

    最后,我们还需要编写一个LazyDataSource来支持这个LazyConnecitonProxy

    1. public class LazyDataSource implements DataSource {
    2. private String url;
    3. private String username;
    4. private String password;
    5. public LazyDataSource(String url, String username, String password) {
    6. this.url = url;
    7. this.username = username;
    8. this.password = password;
    9. }
    10. public Connection getConnection(String username, String password) throws SQLException {
    11. return new LazyConnectionProxy(() -> {
    12. try {
    13. Connection conn = DriverManager.getConnection(url, username, password);
    14. System.out.println("Open connection: " + conn);
    15. return conn;
    16. } catch (SQLException e) {
    17. throw new RuntimeException(e);
    18. }
    19. });
    20. }
    21. ...
    22. }

    我们执行代码,输出如下:

    可见第一个getConnection()调用获取到的LazyConnectionProxy并没有实际打开真正的JDBC Connection。

    1. DataSource pooledDataSource = new PooledDataSource(jdbcUrl, jdbcUsername, jdbcPassword);
    2. try (Connection conn = pooledDataSource.getConnection()) {
    3. }
    4. try (Connection conn = pooledDataSource.getConnection()) {
    5. // 获取到的是同一个Connection
    6. }
    7. try (Connection conn = pooledDataSource.getConnection()) {
    8. // 获取到的是同一个Connection
    9. }

    调用方并不关心是否复用了Connection,但从PooledDataSource获取的Connection确实自带这个优化功能。如何实现可复用Connection的连接池?答案仍然是使用代理模式。

    1. Connection target;
    2. // 空闲队列:
    3. Queue<PooledConnectionProxy> idleQueue;
    4. public PooledConnectionProxy(Queue<PooledConnectionProxy> idleQueue, Connection target) {
    5. this.idleQueue = idleQueue;
    6. this.target = target;
    7. }
    8. public void close() throws SQLException {
    9. System.out.println("Fake close and released to idle queue for future reuse: " + target);
    10. // 并没有调用实际Connection的close()方法,
    11. // 而是把自己放入空闲队列:
    12. idleQueue.offer(this);
    13. }
    14. protected Connection getRealConnection() {
    15. return target;
    16. }
    17. }

    复用连接的关键在于覆写close()方法,它并没有真正关闭底层JDBC连接,而是把自己放回一个空闲队列,以便下次使用。

    空闲队列由PooledDataSource负责维护:

    1. public class PooledDataSource implements DataSource {
    2. private String url;
    3. private String username;
    4. private String password;
    5. // 维护一个空闲队列:
    6. private Queue<PooledConnectionProxy> idleQueue = new ArrayBlockingQueue<>(100);
    7. public PooledDataSource(String url, String username, String password) {
    8. this.url = url;
    9. this.username = username;
    10. this.password = password;
    11. }
    12. public Connection getConnection(String username, String password) throws SQLException {
    13. // 首先试图获取一个空闲连接:
    14. PooledConnectionProxy conn = idleQueue.poll();
    15. if (conn == null) {
    16. // 没有空闲连接时,打开一个新连接:
    17. conn = openNewConnection();
    18. } else {
    19. System.out.println("Return pooled connection: " + conn.target);
    20. }
    21. return conn;
    22. }
    23. private PooledConnectionProxy openNewConnection() throws SQLException {
    24. Connection conn = DriverManager.getConnection(url, username, password);
    25. System.out.println("Open new connection: " + conn);
    26. return new PooledConnectionProxy(idleQueue, conn);
    27. }
    28. ...

    我们执行调用方代码,输出如下:

    除了第一次打开了一个真正的JDBC Connection,后续获取的Connection实际上是同一个JDBC Connection。但是,对于调用方来说,完全不需要知道底层做了哪些优化。

    我们实际使用的DataSource,例如HikariCP,都是基于代理模式实现的,原理同上,但增加了更多的如动态伸缩的功能(一个连接空闲一段时间后自动关闭)。

    有的童鞋会发现Proxy模式和Decorator模式有些类似。确实,这两者看起来很像,但区别在于:Decorator模式让调用者自己创建核心类,然后组合各种功能,而Proxy模式决不能让调用者自己创建再组合,否则就失去了代理的功能。Proxy模式让调用者认为获取到的是核心类接口,但实际上是代理类。

    从下载练习:使用代理模式编写一个JDBC连接池 (推荐使用快速下载)

    小结

    代理模式通过封装一个已有接口,并向调用方返回相同的接口类型,能让调用方在不改变任何代码的前提下增强某些功能(例如,鉴权、延迟加载、连接池复用等)。

    使用Proxy模式要求调用方持有接口,作为Proxy的类也必须实现相同的接口类型。

    代理 - 图2