<think>我们面对的问题是：在使用Druid连接池时，调用`getMaxFieldSize`方法出现错误，提示`
java.sql.SQLException: No operations allowed after statement closed`。这意味着在语句关闭后尝试执行操作。
### 问题分析
1
. **错误信息含义**：`
No operations allowed after statement closed`表示在数据库语句（
Statement）已经被关闭后，仍然尝试对其进行操作（如调用`getMaxFieldSize`方法）。这通常是因为程序在某个地方关闭了语句，但后续又尝试使用它。
2
. **Druid连接池的特性**：Druid连接池会缓存Prepared
Statement以提高性能。但在某些情况下，如果缓存中的语句已经被关闭（可能是由于程序中的错误关闭，或者是连接池内部的问题），当连接池将该语句分配给新的请求时，就会导致此错误。
3
. **可能的原因**：
- 程序代码中显式关闭了Prepared
Statement，但后续又尝试使用它（例如，在try-with-resources块外使用）。
- 连接池配置不当，导致语句被过早回收或关闭。
- Druid连接池的版本存在已知问题（如引用[1]中提到的1
.0
.28版本的问题，在1
.0
.29中修复了类似问题）。
- 数据库连接被意外关闭（如网络问题、数据库超时等），导致其下的所有语句都变为关闭状态。
### 解决方案
根据上述分析，我们可以从以下几个方面解决：
#### 1
. 检查程序代码
确保在使用Prepared
Statement时，遵循正确的关闭顺序。不要在使用完毕后再次使用已关闭的语句。推荐使用try-with-resources确保资源正确关闭：
```
java
try (
Connection conn = dataSource
.get
Connection();
Prepared
Statement stmt = conn
.prepare
Statement(
sql)) {
// 使用stmt执行操作
} // 自动关闭stmt和conn
```
注意：不要在try块外使用stmt。
#### 2
. 升级Druid版本
引用[1]中提到，类似的问题在Druid 1
.0
.28中存在，并在1
.0
.29中通过优化psCache（Prepared
Statement缓存）修复。因此，升级到1
.0
.29或更高版本可能解决此问题。
在pom
.xml中更新版本：
```xml
<dependency>
<groupId>com
.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1
.0
.29</version> <!-- 或更高版本 -->
</dependency>
```
#### 3
. 调整Druid配置
检查Druid连接池的配置，特别是与语句缓存相关的配置：
- `maxPoolPrepared
StatementPer
ConnectionSize`：设置每个连接上缓存的Prepared
Statement数量。如果设置过小，可能导致缓存被提前清除。
- `removeAbandoned`：是否移除废弃的连接。如果为true，可能会在语句仍在使用时被回收。
- `validationQuery`：配置一个用于检测连接有效性的
SQL查询（如`SELECT 1`），并设置`testOnBorrow`或`testOnReturn`为true，确保连接有效。
示例配置（application
.properties）：
```properties
spring
.datasource
.druid
.maxPoolPrepared
StatementPer
ConnectionSize=10
spring
.datasource
.druid
.removeAbandoned=true
spring
.datasource
.druid
.removeAbandonedTimeout=300 # 超时时间（秒）
spring
.datasource
.druid
.validationQuery=SELECT 1
spring
.datasource
.druid
.testOnBorrow=true
```
#### 4
. 检查数据库连接状态
确保数据库连接没有因为超时而被关闭。可以通过增加数据库的超时设置或调整连接池的保活机制（如`timeBetweenEvictionRunsMillis`和`minEvictableIdleTimeMillis`）来避免连接超时。
### 总结
该错误通常由以下原因之一引起：
- 代码中错误地使用了已关闭的语句。
- Druid连接池的缓存机制问题（升级版本可解决）。
- 连接池配置不当导致语句被提前关闭。
建议先升级Druid版本至1
.0
.29或更高，并检查代码中语句的使用方式。如果问题仍然存在，再调整连接池配置。
§§相关问题§§
1
. 如何正确关闭Druid连接池中的Prepared
Statement？
2
. Druid连接池的常见配置参数有哪些？如何优化？
3
. 除了升级版本，还有哪些方法可以解决Druid连接池的缓存问题？</think>### Druid连接池 'getMaxFieldSize' 方法报错分析及解决方案
#### 问题原因分析
1
. **语句关闭后操作**
错误信息 `
No operations allowed after statement closed` 表明程序尝试在数据库语句（
Statement/Prepared
Statement）关闭后执行操作（如调用 `getMaxFieldSize()`）。这通常发生在：
- 连接池中的语句被意外关闭
- 程序逻辑中提前关闭了语句但后续仍尝试使用
- 数据库连接因超时被自动关闭
2
. **Druid连接池缓存机制**
引用[1]指出：Druid会缓存Prepared
Statement（PS Cache），当某条
SQL执行出错时，错误信息会保留在对应线程中。后续使用该线程的新
SQL会直接报错而不执行[^1]。
3
. **版本缺陷**
在Druid <1
.0
.29版本中，PS Cache存在缺陷可能导致问题线程未被正确清理（引用[1]明确提到1
.0
.29修复了此问题）[^1]。
#### 解决方案
1
. **升级Druid版本（首要推荐）**
升级到1
.0
.29+版本，该版本优化了PS Cache的清理机制：
```xml
<dependency>
<groupId>com
.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1
.0
.29</version> <!-- 或更高版本 -->
</dependency>
```
2
. **检查代码资源关闭逻辑**
确保遵循标准的资源关闭顺序：
```
java
// 正确关闭顺序：ResultSet ->
Statement ->
Connection
try (Prepared
Statement ps = conn
.prepare
Statement(
sql);
ResultSet rs = ps
.executeQuery()) {
// 操作结果集
} // 自动关闭资源
```
避免在业务逻辑中手动调用 `
statement.close()` 后再次使用该语句。
3
. **调整连接池配置**
在 `application
.yml` 中添加：
```yaml
spring
:
datasource
:
druid
:
# 关闭PS缓存（可能影响性能）
poolPrepared
Statements
: false
# 或调整PS缓存大小
maxPoolPrepared
StatementPer
ConnectionSize
: 20
# 设置连接保活检测
validationQuery
: SELECT 1
testWhileIdle
: true
timeBetweenEvictionRunsMillis
: 60000
```
4
. **检查
SQL执行异常**
定位首次触发错误的
SQL语句（查看日志中更早的异常），修复
SQL语法或参数错误，避免产生"污染线程"。
#### 问题重现逻辑
```mermaid
graph TD
A[错误
SQL执行] --> B[线程标记为错误状态]
B --> C[线程放回连接池]
C --> D[新请求获取该线程]
D --> E[执行getMaxFieldSize等操作]
E --> F[抛出
No operations allowed after statement closed]
```
#### 总结建议
优先升级Druid至1
.0
.29+版本（修复PS Cache问题），其次检查：
1
. SQL语句正确性
2
. 资源关闭顺序
3
. 连接池配置（如关闭PS缓存）
若升级后仍出现，需检查是否有其他线程未正确处理
SQL异常[^1][^2]。
本文解释了MySQL服务器默认的“wait_timeout”为8小时，即一个connection空闲超过8小时后，MySQL会自动断开连接。为了避免这种情况，建议在每次建立数据库链接时创建对象，并在使用结束后手动关闭。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
