文章目录
- 回顾 Tomcat 部署 WAR 应用报错找不到数据库驱动的问题
- ChatGPT、Javadoc 和 MySQL 驱动都说没必要 `Class.forName()`
- 实验
- 创建一个最小复现问题的 Demo
- 不调用 `Class.forName("com.mysql.cj.jdbc.Driver")`
- 调用 `Class.forName("com.mysql.cj.jdbc.Driver")`
- 为什么找不到驱动?原因很简单
- Java 8 源码
- Java 17 源码
- 结论
前段时间,有同学在使用 Apache ShardingSphere-JDBC 时遇到报错 java.sql.SQLException: No suitable driver
。经过调查,发现这个问题和使用独立 Tomcat 部署应用有关。
相信做 Java 的同学对以下这段代码都不陌生。JDBC 获取一个数据库连接,然后使用这个连接做增删改查操作。
Class.forName("com.mysql.jdbc.Driver");
Connection conn = DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306");
自 Java 引入 SPI 机制后,JDBC 的驱动可以注册为 SPI 的实现类,一般情况无须再通过 Class.forName
加载。但是,有些场景
探究独立 Tomcat 报错 java.sql.SQLException: No suitable driver 的根本原因
回顾 Tomcat 部署 WAR 应用报错找不到数据库驱动的问题
经历过 Tomcat 部署 WAR 包的开发者,可能多少都有遇到过,明明项目的 lib 目录下已经有了数据库驱动,但是应用却仍然报错 No suitable driver
:
getConnection: no suitable driver found for jdbc:mysql://127.0.0.1:3306
java.sql.SQLException: No suitable driver found for jdbc:mysql://127.0.0.1:3306
at java.sql.DriverManager.getConnection(DriverManager.java:689)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at icu.wwj.hello.tomcat.driverdemo.HelloServlet.doGet(HelloServlet.java:18)
当然,去网上查一下会有很多解决方法的搜索结果,主要都是:
- 确保已经添加了驱动;
- 检查 JDBC URL 确保没有写错;
- 把驱动放进 Tomcat 的 lib 目录(甚至有放进 JRE lib 目录的方法);
- 获取连接前先调用
Class.forName("com.mysql.jdbc.Driver")
; - ……
至此,基本大多数场景找不到驱动的问题都能解决。但是,为什么把驱动放进 Tomcat 的 lib 目录,或者先调用 Class.forName()
能够解决问题?
看看 ChatGPT 提供的答案:
看起来与 Tomcat 的类加载器、部署机制有关系。
ChatGPT、Javadoc 和 MySQL 驱动都说没必要 Class.forName()
ChatGPT 的说法:
JDK 8 的 DriverManager 的 javadoc 中有这么一段话:
Applications no longer need to explicitly load JDBC drivers using Class.forName(). Existing programs which currently load JDBC drivers using Class.forName() will continue to work without modification.
意思就是应用程序不再需要通过 Class.forName()
显式加载 JDBC 驱动了,已有的程序这么干了也没问题。
追踪了一下历史,这段话在 GitHub OpenJDK 仓库的初始提交 中就已经存在了,所以是谁在什么时候写的也就不知道了。
就连 MySQL Connector/J 8.0.x 也输出警告说:驱动自动通过 SPI 注册,没有必要手动加载驱动类了:
package com.mysql.jdbc;
import java.sql.SQLException;
/**
* Backwards compatibility to support apps that call <code>Class.forName("com.mysql.jdbc.Driver");</code>.
*/
public class Driver extends com.mysql.cj.jdbc.Driver {
public Driver() throws SQLException {
super();
}
static {
System.err.println("Loading class `com.mysql.jdbc.Driver'. This is deprecated. The new driver class is `com.mysql.cj.jdbc.Driver'. "
+ "The driver is automatically registered via the SPI and manual loading of the driver class is generally unnecessary.");
}
}
在 JDK 9,这套说辞被改掉了:
DriverManager 的驱动加载变成了懒加载,并使用线程上下文累加载器触发 SPI 机制加载驱动。应用程序加载和可用的驱动程序将取决于触发驱动程序初始化的线程的线程上下文类加载器。
虽然 SPI 加载驱动的时机做了调整,但一般情况下不需要显式调用 Class.forName
这点还是不变的。
实验
创建一个最小复现问题的 Demo
准备一个独立 Tomcat 并写一个简单的 Servlet,通过调试和源码分析为什么使用独立 Tomcat 会遇到 No suitable driver 的问题。
题外话:以前学习 Servlet 的时候都没有用过注解,都是在
web.xml
写一堆配置。使用自 Servlet 3.0 的注解,写一个 Servlet 的 hello, world 快多了,不需要像以前那样在web.xml
写一堆配置了。
实现一个 HTTP GET 方法,在里面尝试获取数据库连接。
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.sql.Connection;
import java.sql.DriverManager;
@WebServlet(name = "driver", value = "/driver")
public class HelloServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
response.setContentType("text/plain");
DriverManager.setLogWriter(response.getWriter()); // 将 JDBC 日志直接输出到 HTTP 响应
// try { Class.forName("com.mysql.cj.jdbc.Driver"); } catch (ClassNotFoundException e) { response.getWriter().println(e); }
try (Connection c = DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306", "root", "root")) {
response.getWriter().println("Connected to MySQL " + c.getMetaData().getDatabaseProductVersion());
} catch (Exception ex) {
response.getWriter().println();
}
}
}
不调用 Class.forName("com.mysql.cj.jdbc.Driver")
考虑到不同版本 Java 的 DriverManager 存在差异,尝试过以下版本,均发生同样的错误:
- Java 8
- Java 17
- Java 20(本文编写时 Java 已发布的最新版本)
Java 8 输出结果如下,Java 17 与 Java 20 的输出除了 DriverManager.java 的行数不一样外,其他完全一样。
$ curl -s 127.0.0.1:8080/driver
DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306")
getConnection: no suitable driver found for jdbc:mysql://127.0.0.1:3306
java.sql.SQLException: No suitable driver found for jdbc:mysql://127.0.0.1:3306
at java.sql.DriverManager.getConnection(DriverManager.java:689)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at icu.wwj.hello.tomcat.driverdemo.HelloServlet.doGet(HelloServlet.java:18)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:529)
# ... 省略 Tomcat 调用栈
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:750)
SQLException: SQLState(08001)
调用 Class.forName("com.mysql.cj.jdbc.Driver")
数据库操作正常执行。
$ curl -s 127.0.0.1:8080/driver
registerDriver: com.mysql.cj.jdbc.Driver@547a2eb2
DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306")
trying com.mysql.cj.jdbc.Driver
getConnection returning com.mysql.cj.jdbc.Driver
Connected to MySQL 5.7.36
接下来笔者将探究问题的根本原因。
为什么找不到驱动?原因很简单
Java 8 源码
本节源码选自 JDK Azul Zulu Community 1.8.0_372
DriverManager 在 static 方法中通过系统变量、配置文件、SPI 加载 JDBC 驱动。
java.sql.DriverManager
源码节选
public class DriverManager {
// List of registered JDBC drivers
private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers = new CopyOnWriteArrayList<>();
// 省略部分代码
/**
* Load the initial JDBC drivers by checking the System property
* jdbc.properties and then use the {@code ServiceLoader} mechanism
*/
static {
loadInitialDrivers();
println("JDBC DriverManager initialized");
}
// 省略其余代码
打个断点调试发现,loadInitialDrivers()
方法执行完后,registeredDrivers
却是空的。查看代码调用栈,发现目前正处于 Tomcat 的启动阶段。MySQL JDBC 驱动在应用 WAR 包内,而应用的 WAR 包是在 Tomcat 启动完成后才开始加载的。
也就是,Tomcat 正在启动的时候就已经初始化了类 DriverManager,但此时 WAR 包还没有部署,所以 DriverManager 通过 SPI 加载不到任何驱动。
Java 17 源码
Java 17 的 DriverManager 已经不在 static
代码块中调用 SPI 加载 JDBC 驱动类了,但问题的表现与 Java 8 却是一致的。调试发现,问题其实还是与 Tomcat 有关。
Tomcat 的 JreMemoryLeakPreventionListener.java
会调用一次 DriverManager.getDrivers()
方法,正是这个方法调用触发了 DriverManager 使用 SPI 加载驱动。
虽然 DriverManager 通过 SPI 加载驱动的时机变化了,但加载还是只会进行一次。所以后续通过 WAR 包部署应用,DriverManager 不会再通过 SPI 加载驱动了。
结论
- java.sql.DriverManager 只会调用一次 SPI 加载 JDBC 驱动;
- Tomcat 在启动时,部署 WAR 包应用前,调用了 DriverManager 的方法,触发了 SPI 加载机制;
于是,WAR 包中的 JDBC 驱动错过了 SPI JDBC 驱动加载,驱动无法自动注册。