orm 建立在 jdbc 之上，依赖其获取 resultset 并通过元数据、反射和类型转换完成对象映射；所有 orm 框架均基于 jdbc 接口实现，无一例外。
Java 中 JDBC 与 ORM 框架的映射关系，不是“配合”，而是ORM 建立在 JDBC 之上，完全依赖 JDBC 完成实际的数据读写。JDBC 是执行层，ORM 是封装层；没有 JDBC，ORM 就无法拿到 ResultSet，也就无从映射。
ResultSet 是映射的唯一源头
所有 ORM（MyBatis、Hibernate、JPA 实现等）最终都调用 PreparedStatement.executeQuery() 得到 ResultSet。这个结果集是一行行原始数据库记录，每行含列名和值（Object 类型），但还不是 Java 对象。ORM 的全部工作，就是把这一行行 ResultSet 解析出来，填进对应的 Java 实体类里。
- MyBatis 的
ResultSetHandler、Hibernate 的Loader、JPA 的EntityLoader，本质都是 ResultSet 遍历器 - 它们不会绕过 JDBC 去直连数据库协议，也不会自己解析 MySQL 网络包——那是 JDBC 驱动干的事
- 即使用了连接池（如 HikariCP），获取的 Connection 仍是标准 JDBC 接口，底层仍是 DriverManager 或 DataSource 创建的物理连接
映射三步走：元数据 + 反射 + 类型转换
ORM 不是魔法，它把 JDBC 手动映射的重复劳动自动化，核心就靠这三件事：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
元数据驱动：通过注解（
@Table、@Column）、XML 或类扫描，提前知道 “User.class ↔ user 表”、“id 字段 ↔ id 列” -
反射操作对象：用
Class.getDeclaredMethod("setId", Long.class)获取 setter，再用method.invoke(user, rs.getLong("id"))赋值；或直接用Field.setAccessible(true)写私有字段 -
类型安全转换：把
rs.getObject("create_time")返回的java.sql.Timestamp自动转成LocalDateTime，把null映射为包装类Integer而非基本类型int
性能关键：Class Cache 缓存反射开销
频繁反射（getMethod、getDeclaredField）很慢。ORM 框架底层普遍采用 Class Cache 优化：
- 首次处理 User 类时，缓存它的无参构造器、所有 setter 方法、字段与列名映射表
- 后续映射同一类对象时，直接复用缓存的 Method 和 Field，跳过查找、权限检查、泛型擦除等开销
- 缓存结构常用
ConcurrentHashMap<class>, Reflector></class>，Reflector 内部封装了 setter 映射、构造器、属性别名等 - 用
SoftReference包装反射对象，避免内存泄漏，让 JVM 在压力大时自动回收
命名约定简化映射逻辑
不用每个字段都写 @Column(name = "user_name")，是因为 ORM 默认启用下划线转驼峰规则：
- 数据库列
user_name→ 自动匹配 Java 属性userName - 列
create_time→ 匹配createTime，再通过类型推导调用rs.getTimestamp("create_time") - 该规则在启动时扫描实体类字段一次生成映射表，之后固化使用，不参与每次查询逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
