正文

这是最近读到的讲关于 JDBC 的超时问题最透彻的文章，原文是http://www.cubrid.org/blog/understanding-jdbc-internals-and-timeout-configuration ，网上现有的翻译感觉磕磕绊绊的，很多上下文信息丢失了，这里用我的理解重新翻译一下。

应用程序中配置恰当的 JDBC 超时时间能减少服务失败的时间，这篇文章我们将讨论不同种类的超时和推荐的配置。

Web 应用服务器在 DDoS 攻击后变得无响应

(这是一个真实案例的发生过程复述)

在 DDoS 攻击之后，整个服务都不能正常工作了，因为第四层交换机不能工作，网络连接断开了，这也导致 WAS （ 可以将 WAS 理解为作者公司的应用程序 ）不能正常工作。攻击发生后不久，安全团队拦截了所有 DDoS 攻击，然后网络恢复正常，但 WAS 还是不能工作。

通过分析系统的 dump 日志发现，业务系统停在了 JDBC API 的调用上。20分钟后系统仍处于等待状态无法响应，大概过了30分钟，系统突然发生异常，然后服务恢复正常。

为什么已经将查询超时时间设置成3秒， WAS 却等待了30分钟？为什么30分钟后 WAS 又开始工作了？

如果理解了 JDBC 的超时机制就能找到答案。

为什么我们需要知道 JDBC 驱动

当有性能问题或系统级错误时，WAS 和数据库是我们关注的两个重要层面。在我公司 WAS 和数据库通常由不同的部门负责，因此每个部门聚焦在各自负责的领域来设法弄清楚状况。此时 WAS 和数据库之间的部分会因为得不到足够的关注而产生盲区。对于 Java 应用，这个盲区在数据库连接池和 JDBC 之间，本文我们将重点讨论 JDBC。

什么是 JDBC 驱动

JDBC 是 Java 应用程序中用于访问数据库的一套标准 API，Sun 公司定义了 4种类型的 JDBC 驱动 。我公司主要用的是第4种，该类型驱动由纯 Java 语言编写，在 Java 应用中通过 socket 与数据库通信。

类型4驱动是通过 socket 来处理字节流的，它的基本操作和 HttpClient 这种网络操作类库相同。同其他网络类库一样，也会在发生超时的时候占用大量的 CPU 资源从而失去响应。如果你之前用过 HttpClient ，肯定遇到过因为没有设置超时导致的错误。如果 socket 超时设置不合适，类型4驱动也可能有同样的错误（连接被阻塞）。

下面让我们了解如何配置 JDBC 驱动的 socket 超时，以及设置时需考虑哪些问题。

WAS 与数据库间的设置超时的层次

图2展示了简化的 WAS 和数据库通信时的超时层次。

更上层的超时依赖于下层的超时，只有当较低层的超时机制正常工作，上层的超时才会正常。如果 JDBC 驱动程序的 socket 超时工作不正常，那么更上层的超时比如 Statement 超时和事务超时都不会正常工作。

我们收到很多评论说：

即使配置了 Statement 超时，应用程序还是不能从故障中恢复，因为 Statement 超时在网络故障时不起作用。

Statement 超时在网络故障时不起作用 。它只能做到：限制一次Statement 执行的时间，处理超时以防网络故障必须由 JDBC 驱动来做。

JDBC 驱动的 socket 超时还会受操作系统的 socket 超时配置的影响。这解释了为什么案例中的 JDBC 连接在网络故障后阻塞了30分钟才恢复，即使没配置 JDBC 驱动的 socket 超时。

DBCP 连接池位于图2的左边。你会发现各种层面的超时与 DBCP 是分开的。DBCP 负责数据库连接（即本文中说到的 Connection ）的创建和管理，并不涉及超时的处理。当在 DBCP 中创建了一个数据库连接或发送了一条查询校验的 sql 语句用于检查连接有效性时，socket 超时会影响这些过程的处理，但并不直接影响应用程序。

然而在应用程序中调用 DBCP 的 getConnection() 方法时，你能指定应用程序获取数据库连接的超时时间，但这和 JDBC 的连接超时无关。

什么是事务超时

事务超时 是在框架（Spring、EJB容器）或应用程序层面上才有效的超时。

事务超时可能是个不常见的概念。简单讲，事务超时等于** Statement 超时 * N（需要执行的 Statement 的数量） + 其它（垃圾回收等其他时间）**。事务超时被用来限制执行一个事务之内所有 Statement 执行的总时长。

比如，假设执行一次 Statement 执行需0.1秒，那执行几次 Statement 并不是什么问题，但如果是执行十万次则需要一万秒（大约7个小时），这就可以用上事务超时了。

EJB 的声明式事务管理 (容器管理事务) 就是一种典型的使用场景，但声明式事务管理只是定义了相应的规范，容器内事务的处理过程和具体实现由容器的开发者负责。我们公司并没有用 EJB，用的是最常见的 Spring 框架，所以事务超时的配置也由 Spring 来管理。在 Spring 中，事务超时可以在 XML 文件显式配置或在 Java 代码中用 Transactional 注解来配置。

<tx:attributes>
        <tx:method name="…" timeout="3"/>
</tx:attributes>

Spring 提供的事务超时的配置非常简单，它会记录每个事务的开始时间和消耗时间，当特定的事件发生时会对已消耗掉的时间做校验，如果超出了配置将抛出异常。

Spring 中数据库连接被保存在线程本地变量（ThreadLocal）中，这被称作事务同步（Transaction Synchronization）。当数据库连接被保存到 ThreadLocal 时，同时会记录事务的开始时间和超时时间。所以通过数据库连接的代理创建的 Statement 在执行时就会校验这个时间。

EJB 的声明式事务管理的实现也是类似，实现的思路非常简单。如果事务超时非常重要，但你所使用的容器或框架不提供此功能，你也可以选择自己实现，关于事务超时并没有制定标准的 API。

Lucy 框架的1.5和1.6版不支持事务超时，但你可以通过 Spring 的事务管理达到相同的效果。

假设一个事务里有5条 Statement ，每条 Statement 执行时间是200毫秒，其它业务逻辑或框架操作的执行时间是100毫秒，那事务允许的超时时间至少应该1100毫秒（200 * 5 + 100）。

什么是 Statement 超时

Statement 超时是用来限制 Statement 的执行时间的，它的具体值是通过 JDBC API 来设置的。JDBC 驱动程序基于这个值进行 Statement 执行时的超时处理。Statement 超时是通过 JDBC API 中java.sql.Statement 类的 setQueryTimeout(int timeout) 方法配置的。不过现在的开发者已经很少直接在代码中配置它了，更多是通过框架来进行设置。

以 iBatis 为例，可以通过 SqlMapConfig.xml 中的 setting 属性defaultStatementTimeout 来设置全局的 statement 超时缺省值。你也可以通过在具体的 sql 映射文件中的 select insert update 标签的 statement 属性来覆盖。

当你用 Lucy 1.5或1.6版时，可以通过设置 queryTimeout 属性在数据源层面设置 Statement 超时。

Statement 超时的具体数值需要根据每个应用自身的情况而定，并没有推荐的配置。

JDBC 驱动中的 Statement 超时处理过程

每个数据库和驱动程序的 Statement 超时的处理也是不同的。Oracle 和 SQLServer 的工作方式比较像，MySQL 和 CUBRID 比较像。

Oracle 中的 Statement 超时处理

1. 调用 Connection 的 createStatement() 方法创建一个 Statement 对象
2. 调用 Statement 的 executeQuery() 方法
3. Statement 通过内部绑定的 Connection 对象将查询命令发送到 Oracle 数据库
4. Statement 向 Oracle 的超时处理线程 OracleTimeoutPollingThread （每个类加载器一个该线程）注册一个 Statement 用于处理超时
5. 发生超时
6. Oracle 的 OracleTimeoutPollingThread 调用 OracleStatement 的 cancel() 方法
7. 通过 Statement 的 Connection 发送一条消息取消还在执行的查询

请到「今天看啥」查看全文