Java中用JDBC实现用户信息管理系统，核心在于规避连接泄漏、SQL注入、事务失控等风险：须用try-with-resources关闭资源，PreparedStatement绑定参数防注入，HikariCP管理连接池，显式控制事务。
Java中用JDBC实现用户信息管理系统，核心不是“能不能做”，而是“要不要自己写”。JDBC本身只负责连接和执行SQL，不提供CRUD封装、连接池、事务管理或对象映射——这些都得你手动补全。直接裸用JDBC写完整系统，容易在连接泄漏、SQL注入、事务失控上翻车。
如何避免Connection泄漏导致程序卡死
JDBC的Connection、Statement、ResultSet都是资源型对象，必须显式关闭。但try-catch嵌套多层后，异常发生时容易漏关。
- 用try-with-resources语法，让JVM自动关闭（Java 7+）：
try (Connection conn = DriverManager.getConnection(url, user, pwd); PreparedStatement ps = conn.prepareStatement("SELECT * FROM user WHERE id = ?"); ResultSet rs = ps.executeQuery()) { // 处理结果 } - 别在finally里手动
close()——如果conn是null或已关闭，会抛SQLException；try-with-resources已处理空值和重复关闭 - 连接不能复用：一个
Connection实例不应跨多个DAO方法传递，否则线程安全和事务边界会混乱
PreparedStatement比Statement安全在哪
用户输入直接拼接SQL字符串（用Statement + String.format或+）等于给SQL注入开后门。比如用户名输入' OR '1'='1，就可能绕过登录校验。
-
PreparedStatement预编译SQL，参数走二进制协议传输，数据库不会把参数当SQL语法解析 - 所有用户输入字段（如
name、email）必须用setString()等方法绑定，绝不用String.format("INSERT INTO user VALUES ('%s')", name) - 主键自增场景下，用
ps.executeUpdate()后调ps.getGeneratedKeys()取ID，而不是先SELECT MAX(id)——后者在并发插入时会错
为什么别手写Connection管理而要用HikariCP
每次DriverManager.getConnection()都新建TCP连接，耗时约50–200ms。用户列表页查10条记录，若每个getUserById()都新开连接，页面响应直接破秒。
立即学习“Java免费学习笔记（深入）”；
- HikariCP初始化时建好连接池（如
maximumPoolSize=10），后续dataSource.getConnection()只是从池里取空闲连接，毫秒级 - 配置项关键点：
connectionTimeout设为3000（3秒），避免请求卡死；leakDetectionThreshold设为60000（60秒），自动报出未关闭连接的堆栈 - 别把
DataSource实例存在静态变量里——它本身线程安全，但静态持有易导致测试环境无法重置连接池状态
事务控制必须显式commit/rollback
JDBC默认是自动提交（autoCommit=true），每条SQL执行完立刻落库。但用户注册需同时写user表和user_profile表，任一失败都该回滚——这必须关掉自动提交。
- 在同一个
Connection上调用conn.setAutoCommit(false)，再执行多条executeUpdate()，最后统一conn.commit() - 任何异常分支必须
conn.rollback()，且rollback后要确保conn.setAutoCommit(true)恢复原状态，否则后续操作会意外处于事务中 - 别用
ThreadLocal<Connection>手工传事务上下文——这是早期SSH框架的写法，现在应交给Spring的@Transactional或用JTA，裸JDBC里维护它极易出错
真正难的不是写insertUser()方法，而是保证100次并发请求下，连接不耗尽、数据不脏读、转账不丢钱、日志能定位到哪行代码忘了close。这些细节藏在try-with-resources括号里、setAutoCommit(false)的时机里、以及HikariCP配置的毫秒数值里。
