既然作者已经编写了ProxyConnection，为什么要通过javaassist生成HikariProxyConnection？

根据HikariCP的源代码，我发现作者通过javaassist生成HikariProxyConnection，但该类只调用super类方法

例如，HikariProxyConnection的超类是ProxyConnection：

public class HikariProxyConnection extends ProxyConnection implements AutoCloseable, Connection, Wrapper {
   public Statement createStatement() throws SQLException {
     try {
        return super.createStatement();
     } catch (SQLException var2) {
        throw this.checkException(var2);
     }
   }

   public PreparedStatement prepareStatement(String var1) throws SQLException {
     try {
         return super.prepareStatement(var1);
     } catch (SQLException var3) {
         throw this.checkException(var3);
     }
   }    }

我发现ProxyConnection已经做了很多事情，HikariProxyConnection只为每个方法添加了一个try-catch块

如果有人能给出解释，那就太好了。

有一个关于

HikariProxyConnection

的问题，由@brettwooldridge回答：

代理委托给真实的驱动程序类。有些代理，如ResultSet的代理，只截获少数方法。如果没有代码生成，代理将必须实现所有50多个方法，这些方法只是委托给包装的实例

基于反射的代码生成还意味着，当新的JDK版本向现有接口引入新的JDBC方法时，无需执行任何操作

---

关于这一点，我没有权威的答案，但我记得读到Hikari使用javassist在字节码级别作为性能优化。使用字节码，他们可以让JVM静态地（尽可能快地）执行方法调用，而如果他们走装饰器模式路线（即包装类），JVM必须动态调度方法调用（方法重载解析…）。有一个新的答案（作者@brettwooldridge）：从抽象ProxyConnection类生成具体类。任何未被抽象类“重写”且抛出SQLException的方法都会使用以下代码生成委托：。。。这允许我们检查异常，看看它是否代表断开连接错误。一个副作用是，是的，代码在JDBCAPI更改方面是灵活的——至少到目前为止我们遇到的所有更改。我已经看到了。但我不明白这个答案。当JDK版本向现有接口引入新的JDBC方法时，ProxyConnection将改变。并非意味着不需要执行任何操作尽管ProxyConnection是一个抽象类，但作为连接池，实际上必须实现此方法。生成这些类只是为了与高版本JDK兼容？@lucare我建议您对该问题添加评论，以获得“官方”回复