AWS Lambda+JDBI连接PostgreSQL：两种查询方式性能差异咨询

我尝试使用AWS Lambda结合PostgreSQL，并以JDBI作为连接器，但发现两种JDBI查询方式存在性能差异：

方式一：使用接口 #

// Lambda 代码
static{
        jdbi = JdbiConnector.getJdbiInstance();
   }

handler{
      List<Configurations> config = jdbi.withExtension(ConfigurationsDao.class, dao ->{
            return dao.getConfigurationByKey(key);
        });
}

// Config DAO 接口
public interface ConfigurationsDao {

        @SqlQuery("SELECT * from configuration where key = :key")
        @RegisterBeanMapper(Configurations.class)
        public List<Configurations> getConfigurationByKey(@Bind("key") String key);
}

冷启动时Lambda总耗时约5秒，热启动约400-500毫秒。

方式二：直接调用API #

// Lambda 代码
static{
        jdbi = JdbiConnector.getJdbiInstance();
   }

handler{
      List<Configurations> config = new HelperClass().selectUsingJdbi(handle,input.sql);
}

// HelperClass 代码
public class HelperClass{
public List<Configurations> selectUsingJdbi(Handle handle,String val){
        return handle.createQuery("select * from configuration where key = :key")
                     .bind("key",val )
                     .mapToBean(Configurations.class)
                     .collect(Collectors.toList());
        
    }
}

冷启动时Lambda耗时约2-3秒，热启动仅2-3毫秒。

注：数据库连接在冷启动阶段已建立，未计入耗时。接口式写法更简洁，但性能差距明显，请问该差异原因是什么？我是否存在操作错误？

性能差异的核心原因 #

• 动态代理类的生成开销：JDBI接口方式依赖动态代理机制，第一次调用withExtension时，需要为ConfigurationsDao接口生成并加载代理类（底层用ASM库做字节码生成），这个过程在Lambda冷启动的资源受限环境中会消耗大量CPU和时间；而直接API方式不需要生成代理类，直接执行查询逻辑，冷启动阶段的额外开销自然更小。
• 热启动的缓存与校验差异：热启动时，接口方式每次通过withExtension获取DAO实例，仍会执行代理实例初始化、注解规则二次校验（比如@SqlQuery、@Bind的有效性验证），再加上代理调用的额外层级开销，导致耗时维持在数百毫秒；直接API方式则会复用已加载的Bean映射规则和Handle实例，几乎没有额外开销，所以耗时极低。
• Lambda类加载特性限制：Lambda冷启动环境下，类加载器的资源分配有限，动态生成类的操作比常规Java应用更耗时，接口方式正好触发了这个高成本操作。

操作是否存在错误？ #

你的两种写法都没有明显错误：

• 接口方式的withExtension用法符合JDBI官方规范，@SqlQuery、@Bind等注解的使用也完全正确。
• 直接API方式的查询逻辑没问题（只要handler中的handle是正确获取的实例，比如通过jdbi.open()获取，就不存在操作错误）。

接口方式的性能优化建议 #

如果想保留接口写法的简洁性同时提升性能，可以尝试：

• 在Lambda的静态初始化块中提前触发代理类生成，比如添加一行jdbi.withExtension(ConfigurationsDao.class, dao -> null)，把代理类生成的开销转移到冷启动的初始化阶段，避免每次handler调用时重复执行。
• 检查JDBI的配置项，关闭不必要的严格校验特性，减少额外的性能开销。

内容的提问来源于stack exchange，提问作者arsh katyal