本文深入分析 spring boot 应用中 tomcat jdbc 连接池频繁出现“unexpected end of data”异常的根本原因，结合 filemaker jdbc 特性，给出连接池参数调优、空闲连接验证及驱动兼容性等关键解决方案。
本文深入分析 spring boot 应用中 tomcat jdbc 连接池频繁出现“unexpected end of data”异常的根本原因，结合 filemaker jdbc 特性，给出连接池参数调优、空闲连接验证及驱动兼容性等关键解决方案。
在使用 Spring Boot 集成 FileMaker 数据库时，若采用 org.apache.tomcat.jdbc.pool.DataSource 作为连接池，并配置了如 max-active=100、max-idle=15 等参数，初期运行正常，但数小时后却持续抛出如下异常：
SQL State: 08007 Detail Message: [FileMaker][FileMaker JDBC] Unexpected end of data. Error code: 27026
且该异常固定发生在 connection.prepareStatement(...) 调用处——这并非典型的连接获取超时（如 max-wait 触发），而是底层 TCP 连接已中断或服务端主动关闭，但连接池仍将其视为有效连接并复用所致。
根本原因：失效连接未被及时剔除
FileMaker Server 对空闲连接有严格的超时策略（默认通常为 15–30 分钟），而 Tomcat JDBC Pool 默认不主动验证连接有效性。当连接空闲超过 FileMaker 服务端限制后，连接被强制断开，但池中对应 PooledConnection 对象未标记为无效；后续业务线程取出该连接调用 prepareStatement() 时，底层 Socket 已无响应，JDBC 驱动便抛出 “Unexpected end of data” —— 这是 FileMaker JDBC 驱动对底层 I/O 截断的特定错误封装。
仅靠增大 max-active（如答案所提）无法根治问题：它仅缓解并发争抢，但无法解决陈旧连接复用这一核心缺陷。
正确配置方案（application.properties）
需启用连接存活检测与自动清理机制：
# 基础连接池配置（保持原有合理值） spring.datasource.tomcat.initial-size=15 spring.datasource.tomcat.max-active=100 spring.datasource.tomcat.min-idle=8 spring.datasource.tomcat.max-idle=15 spring.datasource.tomcat.max-wait=20000 # ? 关键：启用连接有效性验证 spring.datasource.tomcat.test-on-borrow=true spring.datasource.tomcat.validation-query=SELECT 1 spring.datasource.tomcat.validation-query-timeout=3 # ? 关键：定期清理空闲失效连接（推荐每5分钟检查一次） spring.datasource.tomcat.time-between-eviction-runs-millis=300000 spring.datasource.tomcat.min-evictable-idle-time-millis=600000 # 10分钟以上空闲才考虑回收 # ? 可选：增强健壮性（FileMaker 场景强烈建议） spring.datasource.tomcat.remove-abandoned-on-borrow=true spring.datasource.tomcat.remove-abandoned-timeout=60 spring.datasource.tomcat.log-abandoned=true
✅ 说明：
validation-query=SELECT 1对 FileMaker 有效（无需真实表），配合test-on-borrow可确保每次借出前执行轻量检测；time-between-eviction-runs-millis启动后台驱逐线程，主动关闭长期空闲或验证失败的连接。
补充建议
- 升级 FileMaker JDBC 驱动：确认使用 FileMaker 19+ 官方 JDBC 驱动，旧版存在连接状态同步缺陷；
-
避免
DriverManager.getConnection()对比陷阱：直连无连接复用，自然规避了失效连接问题，但这牺牲了性能与资源管理能力，不可作为生产方案； -
日志监控：开启
logging.level.org.apache.tomcat.jdbc.pool=DEBUG，观察AbandonedConnectionCleanup和ValidationQuery执行日志，验证配置是否生效。
总结
“Unexpected end of data” 在 FileMaker + Tomcat Pool 组合中，本质是连接保活机制失配。解决问题的关键不在扩大容量（max-active），而在于引入连接健康检查（validation-query + test-on-borrow）与主动驱逐（eviction）。正确配置后，可彻底消除数小时后故障复发的现象，实现连接池长期稳定运行。
