本文共 915 字，大约阅读时间需要 3 分钟。

在将代码部署到现网后，厂商遇到了EOF（End of File）问题。通过分析问题表现，发现文件流不完整。进一步排查发现，可能与并发量过大导致接口响应不过来有关。为验证这一猜想，先注释掉MySQL写入逻辑，提升接口性能后再次测试，结果仍存在EOF问题。于是，开始逐步排查性能瓶颈。

首先，在报错时打印CPU、内存、磁盘IO速率，发现这三者都未达到瓶颈，磁盘IO写速度仅剩67MB/s。随后，调整Tomcat连接数配置，但问题依旧存在。于是，简化接口，将其改为最简单的流字节数计算并获取Content Length参数进行比对，试图避免问题的发生。然而，断流问题仍未解决。

为进一步定位问题，建议厂商将他们的demo程序部署到我们的服务器测试。结果发现，他们的程序并未出现断流现象。这表明问题很可能出在我们自己的程序中。尽管已经采用了最基本的流字节遍历方式，但问题依然存在。

在此过程中，我怀疑是否与Spring Boot版本相关。于是，将Spring Boot版本从2.1.13.RELEASE升级到2.7.2，结果问题依然未解决。进一步整理了一个全新的工程，使用2.1.13.RELEASE版本进行测试，结果问题同样未出现。这让我怀疑可能与原工程中的某些切面配置有关，但无法直接验证。

最终，由于客户要求数据报送需要使用HTTPS协议，我整合了HTTPS功能，结果又一次出现了断流问题。此时，问题得以定位。重新整理了一个新的工程包后，出现了另一个问题：厂家在接收数据时偶尔无法读取body中的JSON内容。经过多番测试，问题未出现。后来，厂家自行修改了读取body内容的方式，问题得以解决。

最终，实现了以下效果：每分钟处理1900份数据，2000多次请求，每次50条左右，估算一天可处理1.4亿数据。Tomcat线程配置为：server: port: 8080，tomcat: accept-count: 65535，max-connections: 65535，max-threads: 2000，min-spare-threads: 500以上（基于4核8G内存经验值）。

整个过程持续了大约一周时间，让我几天没得合睡觉。

转载地址：http://jdabz.baihongyu.com/