Java开发中DriverManager与SpringBoot(Hibernate)连接数据库的差异及底层实现疑问

首先明确两种连接方式的基本形态：

• 原生JDBC模式：通过DriverManager手动管理驱动加载、连接创建，核心实现代码为Connection conn = DriverManager.getConnection(url, name, password);
• SpringBoot配置模式：读取application.properties中的数据源、JPA配置项，由框架自动完成连接初始化，典型配置包括spring.datasource.url、spring.jpa.hibernate.ddl-auto等参数，配合@Entity注解即可实现数据持久化。

两者的核心差异主要体现在四个方面：

• 连接复用机制不同：原生DriverManager没有内置连接池能力，每次调用getConnection都会和数据库新建一次物理TCP连接，用完必须手动调用close()销毁。频繁的建连、拆连会带来极高的性能损耗，还容易出现忘关连接导致的数据库连接被占满、应用崩溃的问题。SpringBoot默认集成HikariCP高性能连接池，启动时会按配置提前初始化一批物理连接放在池里，业务代码取连接时直接复用现有连接，用完只需要标记为空闲放回池子，不会反复和数据库做握手建连的操作。
• 配置管理方式不同：原生DriverManager的连接参数通常需要硬编码在代码中，或是自己实现配置文件的读取、解析逻辑，修改参数时需要修改代码重新编译打包。SpringBoot的数据源配置直接内嵌在全局配置文件中，支持多环境配置拆分，修改参数只需要调整配置项、重启应用即可，不需要改动业务代码。
• 生命周期托管程度不同：原生方式下连接的创建、异常处理、销毁全流程都需要开发者手动实现，比如驱动加载失败、连接超时的异常捕获逻辑都要自己编写。SpringBoot的数据源、连接池的生命周期完全由Spring容器托管，应用启动时自动初始化连接池、加载数据库驱动，应用停机时统一回收所有连接，开发者不需要感知底层连接的管理逻辑。
• 上层生态支持不同：原生方式拿到Connection对象后，需要手动编写JDBC语句、处理结果集、管理事务提交/回滚。SpringBoot完成数据源配置后，可以直接对接JdbcTemplate、Spring JPA、MyBatis等封装好的数据访问组件，搭配@Entity注解就能自动完成ORM映射、CRUD语句生成，大幅减少样板代码。

两者的最底层建连逻辑是同源的，但上层封装和使用场景完全不同：

• 从JDBC规范的本质来看，不管是原生DriverManager还是SpringBoot使用的连接池，最终要和数据库建立物理连接时，都需要加载对应数据库的JDBC驱动。而驱动的加载、连接创建的底层逻辑，最早就是由JDBC规范定义的DriverManager类实现的。SpringBoot的连接池在初始化时，本质上也是通过DriverManager（或直接调用Driver接口的建连方法，逻辑完全等价）加载数据库驱动、创建第一批物理连接放入池中。
• 但两者的使用逻辑差异极大：原生方式是让业务代码直接调用DriverManager，每次获取连接都走新建流程；而SpringBoot是把DriverManager的建连动作封装成了连接池的初始化逻辑，业务代码根本不会直接调用DriverManager的方法，拿到的都是池里已经创建好的复用连接，完全不会走到每次新建连接的流程。

内容的提问来源于stack exchange，提问作者Malay Pandey