企业官网建设流程全解析

提到"JDBC驱动"和"Servlet容器"，很多刚入行的Java开发者会觉得这是两个再基础不过的概念，甚至觉得老掉牙了。但我做了这么多年Java Web开发，面试过不少人，也接手过不少烂摊子，发现真正把这两块吃透的人，其实不多。很多人能把Spring Boot项目跑得飞起，但问他Mysql驱动在JDBC里扮演什么角色，Tomcat容器到底在他请求的哪一环做了什么事，往往答不上来。

这篇就围绕这两个主题，把我实际开发中总结的经验、踩过的坑、以及为什么理解了它们就能解决很多"奇怪"线上问题，全部摊开聊一聊。内容适合所有写Java后端的朋友，不管是刚学Servlet的菜鸟，还是用了好几年框架的老手，相信都能找到点有用的东西。

1. JDBC驱动：通往数据库的第一道大门

1.1 驱动到底是什么

简单说，JDBC（Java Database Connectivity）是Java官方定义的一套访问数据库的接口规范，它本身只是一堆接口，没有任何实现。真正干活的是各个数据库厂商提供的驱动，比如Mysql的com.mysql.cj.jdbc.Driver，PostgreSQL的org.postgresql.Driver，Oracle的oracle.jdbc.OracleDriver。

打个比方，JDBC接口是通用的三脚插座标准，驱动就是插在插座上的各种电器插头。插头必须符合插座标准才能通电，驱动必须实现JDBC接口才能被Java程序调用。你换数据库时，程序代码基本不用动，只需要换掉驱动依赖和连接字符串即可，这正是JDBC存在的意义。

驱动内部做的事情，说起来其实不复杂：

• 建立一条到数据库的物理网络连接（通常走TCP）
• 把你的Java方法调用翻译成数据库能懂的协议指令，比如MySQL的客户端/服务端协议
• 把数据库返回的二进制结果集，转换成Java对象，比如ResultSet、RowSet
• 处理游标、事务、预处理语句等底层细节

驱动分几种类型，最常见的是纯Java实现的那种，Type 4驱动，直接通过Socket连接数据库，不需要本地代码库，跨平台部署非常方便。现在主流的MySQL、PostgreSQL驱动基本都是Type 4。

1.2 类加载与DriverManager的机制

很多人在项目里都不写Class.forName("com.mysql.cj.jdbc.Driver")这行代码了，因为现在的JDBC 4.0以上版本支持SPI自动加载。但如果你不理解类加载机制，还是会踩坑。

驱动里的Driver实现类，通常会有一个静态代码块：

static { try { DriverManager.registerDriver(new Driver()); } catch (SQLException e) { throw new RuntimeException("Failed to register driver!", e); } }

当JVM加载这个类时，静态代码块执行，驱动实例自动注册到DriverManager。JDBC 4.0之后，驱动包的META-INF/services/java.sql.Driver文件里声明了驱动类全限定名，DriverManager初始化时会通过ServiceLoader机制自动加载它。这就是为什么你几乎不需要手写Class.forName的原因。

但要注意一个冷知识：如果你把驱动Jar包放在容器（比如Tomcat）的lib目录，同时又在应用里也放了一份，就可能出现驱动类被加载两次、DriverManager里注册了两个相同驱动实例的情况。虽然通常不会报错，但在某些严格场景下，比如反序列化、类比较时，会引发诡异问题。

1.3 驱动版本选择真的不能大意

我在真实项目里见过太多因为驱动版本不合适导致的线上故障。比如MySQL 8.0的驱动，早期版本mysql-connector-java 5.x连接MySQL 8.0时，如果不调整认证插件配置，直接报Unable to load authentication plugin 'caching_sha2_password'。

那个年代很多人被这个错误折磨过，解决办法无非两种：把数据库用户的认证插件改回mysql_native_password，或者升级驱动到8.x。我个人建议是升级驱动，因为改认证插件虽然方便，但长期来看旧的认证插件安全性不如新插件，而且迟早要升级。

驱动版本选择还要注意：

• 大版本号尽量和数据库大版本保持一致，比如连MySQL 8.0就用8.x驱动，连MySQL 5.7用5.1.x或8.x（注意参数差异）
• 驱动版本和JDK版本有隐性关联，比如新版MySQL驱动要求JDK 8及以上，老的JDK 7项目硬上8.x驱动会报UnsupportedClassVersionError
• 生产环境优先使用GA版本，不要用SNAPSHOT或刚发布的初版

实操心得：升级驱动后，一定要在测试环境回归一遍连接池的创建、连接获取、预处理语句、事务提交回滚这几个核心路径。不要光用SELECT 1测通就完事，驱动升级引发的问题往往在复杂SQL或者大批量操作时才会暴露。

2. Servlet容器：请求的接驳站和处理中枢

2.1 Servlet容器在整个请求链路中的位置

浏览器发一个HTTP请求到后端，经过DNS解析、TCP握手、HTTP报文解析，最后到达你的业务代码。那从"网络报文"到"你写的Java方法"之间，谁在做苦力？答案是Servlet容器。

业内最常用的Servlet容器就是Tomcat、Jetty、Undertow。Spring Boot内嵌的默认容器就是Tomcat。容器负责的事比你想象的多得多：

• 监听端口、接受TCP连接
• 解析HTTP请求头、请求体、Cookie等，封装成HttpServletRequest对象
• 创建一个HttpServletResponse对象供后端写响应
• 根据URL映射规则找到对应的Servlet（或Spring MVC的DispatcherServlet），调用其service()方法
• 管理Servlet的生命周期：加载、初始化、服务、销毁
• 处理线程池、连接复用、Keep-Alive、异步请求等底层细节
• 类加载器的隔离管理，保证不同应用之间的依赖互不冲突

如果你用原生Servlet写过接口，你就会发现写在doGet()、doPost()里的业务逻辑只是整个链路里最薄的一层。真正复杂的HTTP解析和连接管理，全被容器干完了。

2.2 线程模型是性能的关键

Tomcat的经典IO模型常被误传，这里说个清楚。Tomcat有BIO（阻塞IO）和NIO（非阻塞IO）两种模式。现在默认是NIO，即用少量线程处理大量连接，避免了"一个连接一个线程"的资源浪费。

NIO模式下，Poller线程负责扫描所有Socket事件，发现某个连接有数据可读时，就把这个Socket分配给一个工作线程（Worker Thread），然后由工作线程执行Servlet业务逻辑。工作线程执行完，响应写入Socket，线程归还线程池。

理解这个模型有什么用？非常有价值。你调优Tomcat时配的maxThreads就是工作线程池上限。如果业务逻辑里有慢SQL、外部API调用，这些线程会被长时间占用，池子满了之后，新请求就会排队。

有个经典案例：某个系统一到高峰期接口就变慢，但CPU、内存都正常，数据库压力也不大。后来一看Tomcat线程池，线程全部卡在调用外部第三方HTTP接口上，那接口自身响应要5秒，线程被拖死。解决方案是把外部调用改成异步方式，或者用单独的线程池隔离，避免拖垮Tomcat的工作线程。

2.3 Servlet生命周期和容器的启动加载顺序

Servlet的生命周期有明确规范：容器启动时（或首次请求时）加载Servlet类，实例化对象，调用init()方法，之后每次请求调用service()方法，容器关闭时调用destroy()方法。

这里有个开发中很常见的坑：在init()里做了耗时操作，比如初始化数据库连接池，但加载时机设置成首次请求时（load-on-startup不设置或为负数），那么第一个访问这个接口的用户会非常慢，等的时间可能就是init()执行的时间。

要想让Servlet在容器启动时就初始化，用<load-on-startup>1</load-on-startup>配置，数字越小优先级越高。在Spring Boot里，如果你想在应用启动时做一些初始化工作，更优雅的方式是实现ApplicationRunner或CommandLineRunner接口。

另外一个常见问题：容器关闭时destroy()里没有正确释放资源，导致数据库连接池里的连接没有关闭，在开发环境可能看不出来，但在频繁重启的生产环境，数据库端会积累大量僵尸连接，直到把数据库连接数打满。

3. 实际开发中两者的深度绑定

3.1 连接获取：从DriverManager到DataSource

早期Java开发里，拿到数据库连接的办法就是：

Connection conn = DriverManager.getConnection(url, username, password);

这种方法直来直去，但不适合生产。原因很简单：DriverManager.getConnection每次都会创建一个物理连接，频繁创建和销毁数据库连接的开销非常大。生产上必须用连接池，而连接池的核心就是DataSource接口。不管用的是DBCP、C3P0、HikariCP还是Druid，对外暴露的都是DataSource。

为什么连接池能大幅提升性能？原理和线程池一样：池里预先创建一批物理连接，业务代码用的时候从池里借（borrow），用完了归还（return），而不是关闭物理连接。这样省掉了大量TCP握手和数据库认证的开销。

注意事项来了，连接池中的连接是共享资源，如果你在代码里写了：

Connection conn = dataSource.getConnection(); // 业务逻辑 // 忘了close

连接永远不会归还给池子，池子里的可用连接越来越少，最终池子耗尽，所有线程都在等待获取连接，系统直接卡死。排查这种问题，你要看连接池活跃连接数是否一直居高不下，同时看代码里是否有连接从未释放。

3.2 事务边界控制：谁管连接谁管事务

事务和连接是强关联的——一个事务必须在一个连接上完成，事务的提交和回滚都是通过Connection接口来操作的。所以分布式事务的难点也在这里：多个数据库连接无法共享同一个本地事务。

在Servlet + JDBC编程模式中，事务控制可以这样实现：

Connection conn = dataSource.getConnection(); try { conn.setAutoCommit(false); // 多个SQL操作 conn.commit(); } catch (SQLException e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); conn.close(); }

这种写法在纯Servlet阶段没问题，但用Spring的@Transactional之后，事务边界就交给Spring管理了。有一点必须明白：Spring事务管理的核心原理，就是把数据库连接绑定到当前线程上（TransactionSynchronizationManager），在这个线程中执行的DAO操作都拿同一个连接，从而确保事务一致性。

这个机制和Servlet容器有什么关系？非常相关。Tomcat的工作线程池里，每个线程处理完一个请求后会归还线程池，而Spring在请求处理完时清理当前线程的事务资源和连接绑定。万一有异常导致清理没执行，或者说你用了ThreadLocal又没清理，就会出现连接泄漏和事务串号的诡异问题。

3.3 类加载器的恩怨：容器级依赖与应用级依赖

Tomcat采用了"父委托"机制，但和JVM默认的"双亲委派"不完全一样。Tomcat的Web应用类加载器会优先加载WEB-INF/classes和WEB-INF/lib里的类，然后才委托给父类加载器。

这就解释了为什么你经常遇到ClassNotFoundException或NoSuchMethodError但排查半天找不到原因：你的应用里有一个老版本的库，Tomcat的lib目录里有一个新版本的库，而某些类在应用类加载器加载，某些又在公共类加载器加载，版本错乱导致方法签名对不上。

JDBC驱动正好是个典型场景。正确做法是：把JDBC驱动放在容器级类加载器能加载到的位置（Tomcat的lib目录），而应用里不要放。原因在于DriverManager的getConnection是驱动注册在哪个类加载器加载的其实有讲究，但主流做法是驱动放在容器共享目录，连接池自己管理驱动加载则另说。更简单粗暴的方法是：直接弃用DriverManager，统一走DataSource`，让连接池自己负责驱动加载和连接管理。

4. 从构建到部署：实操指南与经验总结

4.1 在传统Web应用中配置Servlet容器和JDBC

尽管现在大多数新项目都用Spring Boot内嵌容器，但理解和掌握传统的Web应用部署仍然非常必要。很多公司遗留系统还是war包方式部署在独立Tomcat里，面试时也常问这个问题。

传统部署有六个关键环节：

1. 创建一个Maven Web项目，打包类型设为war
2. 编写Servlet类，继承HttpServlet，重写doGet或doPost方法
3. 在web.xml中注册Servlet及其URL映射（或用注解@WebServlet）
4. 在pom.xml中加入JDBC驱动依赖，比如连接MySQL用mysql-connector-java
5. 把war包扔到Tomcat的webapps目录下，启动Tomcat自动解压部署
6. 注意驱动Jar包和容器自带Jar包的冲突

一个最简单的Servlet代码：

@WebServlet("/user/list") public class UserListServlet extends HttpServlet { private DataSource dataSource; @Override public void init() throws ServletException { // 在init中初始化连接池，避免首次访问慢 HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:mysql://localhost:3306/test?useSSL=false&serverTimezone=Asia/Shanghai"); config.setUsername("root"); config.setPassword("123456"); config.setMaximumPoolSize(20); dataSource = new HikariDataSource(config); } @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { resp.setContentType("application/json;charset=UTF-8"); String sql = "SELECT id, name FROM t_user LIMIT 10"; try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql); ResultSet rs = ps.executeQuery()) { StringBuilder json = new StringBuilder("["); while (rs.next()) { if (json.length() > 1) { json.append(","); } json.append("{\"id\":").append(rs.getInt("id")) .append(",\"name\":\"") .append(rs.getString("name")) .append("\"}"); } json.append("]"); resp.getWriter().write(json.toString()); } catch (SQLException e) { resp.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR); resp.getWriter().write("{\"error\":\"database error\"}"); log.error("Query user list failed", e); } } }

注意init()方法里初始化连接池的写法，这比在doGet里每次创建连接靠谱得多。用try-with-resources确保连接、语句、结果集都被关闭。

4.2 Spring Boot中的内嵌容器和驱动管理

Spring Boot项目写起来简单，是因为框架把复杂性封装在底层了。你加入spring-boot-starter-web，内嵌的Tomcat自动配好；你加入mysql-connector-j，依赖自动拉下来；你再配置spring.datasource.url、spring.datasource.username、spring.datasource.password，连接池（默认HikariCP）自动创建。

但正因为封装得好，出了问题也更难排查。最常见的翻车现场：

场景一：MySQL驱动包没加或版本不对。启动日志里出现Cannot load driver class: com.mysql.cj.jdbc.Driver。检查pom.xml里有没有：

<dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency>

场景二：时区问题。连接URL里没指定serverTimezone，报The server time zone value '***' is unrecognized。解决办法就在URL里加serverTimezone=Asia/Shanghai。

场景三：连接池配置太小。默认maximum-pool-size是10，如果你系统并发较高，又没调大，请求会大量排队等待连接。配置项直接写：

spring: datasource: hikari: maximum-pool-size: 50 minimum-idle: 10 connection-timeout: 30000

4.3 Tomcat运行时的关键参数调优

接线到这一个大块，必须聊一下Tomcat的线程池参数。无论Spring Boot内嵌Tomcat还是独立Tomcat，你去调整server.tomcat.threads.max（Spring Boot）或maxThreads（独立Tomcat），都是在调整同一批工作线程的数量。

参考经验值：

• 业务逻辑以IO为主（查数据库、调接口），线程数可以设到200~400
• 业务逻辑以CPU计算为主（复杂计算、加解密），线程数建议不要超过CPU核心数的2倍
• 线程数不是越大越好，线程切换有开销，且线程太多会导致连接池、数据库、下游服务压力骤增

server: tomcat: threads: max: 300 min-spare: 20 accept-count: 100 max-connections: 10000

accept-count是等待队列长度。当工作线程满后，新连接会进队列等待。如果队列也满了，后面的请求会被拒绝。这些值要根据实际压测结果来调，不要凭感觉拍脑袋。

4.4 容器和驱动的监控与排查利器

线上出了问题，别急着敲代码，先用工具看清楚现状：

JVisualVM / VisualVM：可以看到Tomcat工作线程池的状态，线程是RUNNABLE还是WAITING还是TIMED_WAITING，一目了然。

Arthas：阿里巴巴开源的Java诊断工具。线上排查神器，比如你想看某个接口到底卡在哪行代码，用trace命令；你想看某个类的实际加载路径，用classloader命令。

JDBC监控：连接池一般都有监控指标，HikariCP可以通过MBean暴露ActiveConnections、TotalConnections、IdleConnections；Druid有专门的监控页面。

平时多盯一个指标：等待获取连接的时间（connectionTimeout相关的统计数据）。如果这个值开始增大，说明连接池快不够用了，要么是流量涨了，要么是存在连接泄漏。

4.5 常见故障排查清单

整理一份我工作中遇到的高频问题速查表：

问题1：启动报Unable to load authentication plugin 'caching_sha2_password'。快查驱动版本，8.x驱动对MySQL 8.0默认认证插件才兼容。

问题2：No suitable driver found for jdbc:mysql://...。要么驱动包没打入，要么DriverManager无法加载驱动，检查Classpath，或者改用DataSource方式连接。

问题3：Too many connections。数据库端连接数被打满，查看连接池最大连接数、应用的连接是否泄漏、是否有其他服务把数据库连接抢占完了。临时可以调大数据库max_connections，但根本办法是定位哪个客户端在泄漏连接。

问题4：Connection is closed或Broken pipe。可能原因：数据库超时杀掉了空闲连接，而连接池没有正确检测和剔除。HikariCP有maxLifetime和connectionTestQuery配置，确保池里的连接是健康的。

问题5：应用启动时卡住不动。检查Tomcat初始化进程，看是不是某个Servlet的init()方法阻塞了，比如连了一个不通的数据库、调了一个不通的中间件。定位方式：jstack 打印线程栈，看线程卡在哪个调用上。

问题6：ClassNotFoundException: org.springframework.web.servlet.DispatcherServlet。典型的war包部署时，Spring相关的Jar包没有打入WEB-INF/lib，或者容器类加载器顺序异常。检查打包插件配置。

5. 写在最后：吃透底层才能不慌

做Java Web这些年，我越来越觉得，很多东西表面上是框架帮你搞定的，但真是出了问题，框架帮不了你，能帮你的只有自己对这个底层机制的理解。

JDBC驱动不是简单的依赖包，它是Java程序连接数据库的契约和通道，理解了驱动加载、连接池管理、事务与连接的绑定关系，SQL层面的问题基本都有方向。Servlet容器不是简单的"启动器"，它是请求从网络到业务的翻译官和调度中心，理解了线程模型、生命周期、类加载隔离，Web层面的问题也都能按图索骥。

如果你正在学Spring Boot，我建议你反着学，先回到原生的Servlet和JDBC，自己写一个不用框架的Web应用，再回过头来看框架帮你做了什么。这个过程里的恍然大悟，比看十篇教程都有用。

最后的实操建议：把依赖清单列清楚，知道每个Jar包的来龙去脉；把配置项弄明白，每改一个参数都清楚它影响的是哪一层；把监控用起来，线上系统必须能看到连接池、线程池、GC这几类核心指标。做到这三件事，Java Web开发里大部分"疑难杂症"在你面前，都不过是例行排查而已。