Android多图片上传时间歇性触发java.net.SocketException: Broken pipe的客户端侧问题排查求助

各位好，我最近被一个间歇性的Socket异常搞到头大：在开发的Android app中，用HttpURLConnection向生产环境的Java服务器上传多张图片时，时不时就会抛出java.net.SocketException: Broken pipe错误，而且完全没规律——大概20次尝试里只有1次能成功完成上传，大部分时候要么上传中途断连，要么写完请求体去拿响应的时候触发异常。想请大家帮忙从客户端侧排查可能的问题，先把我的情况详细说明下：

核心问题与症状 #

• 抛出java.net.SocketException: Broken pipe异常，触发点不固定：有时是在写入请求体的过程中，有时是调用conn.getResponseCode()获取响应的时候
• 间歇性成功：极少数情况下能完整上传所有图片，收到201响应，服务器也能正确接收并存储图片
• 失败时的部分服务器反馈：很多失败案例里，服务器上看不到上传的图片，但运维反馈日志里能抓到POST请求，说明服务器至少接收并处理了部分请求后连接才断开
• 大概率和图片数量/大小相关，但不绝对：多图、大图上传时更容易出问题，但偶尔小图上传也会触发异常

客户端关键实现（核心代码模块） #

我的上传逻辑主要涉及三个Java文件，重点说核心部分：

CameraFragment.java #

• 负责图片拍摄管理，维护File[] capturedImages和imageCount变量
• 会准备好尺寸合规的File[] imagesToUpload作为待上传文件集合
• 启动新线程调用connectionHandler.uploadImages()触发上传流程
• 自我怀疑点：File对象的处理是否足够健壮？会不会在计算文件长度之后、实际读取文件流之前，文件被意外修改或者变得不可访问了？

ConnectionHandler.java #

这是上传逻辑的核心，也是异常的主要触发源：

• uploadImages()方法：先初始化HttpURLConnection，通过「干跑」constructAndSendMultipartFormData()方法计算请求体的总长度（用来设置Content-Length），接着设置请求头、打开输出流，然后再次调用constructAndSendMultipartFormData()实际写入请求体数据
• 异常触发场景分两种：一种是在写数据阶段（比如SocketOutputStream.socketWrite调用ConnectionHandler.transferFileTo时），另一种是写完请求体后拿响应的阶段（比如HttpURLConnectionImpl.getResponseCode调用ConnectionHandler.uploadImages时），最终都是由CameraFragment通过ConnectionHandler发起的上传流程触发
• constructAndSendMultipartFormData()是「两用」方法：干跑时只计算请求体总长度，实际上传时则写入数据，内部会循环调用writeFormField()、writeImageField()构建每个multipart请求部分
• transferFileTo()同样是「两用」：干跑时返回file.length()，实际上传时从FileInputStream读数据并写入连接的OutputStream——这部分是我觉得最可能藏bug的地方

我怀疑问题出在客户端侧的原因 #

1. 间歇性成功的特性：如果是服务器配置问题，应该会100%失败，但运维明确说浏览器上传完全正常，只有我的app会出现上传相关的错误；偶尔成功说明客户端存在某个「大部分时候不满足、偶尔刚好命中」的条件
2. Content-Length的潜在问题：就算是写数据时断连，Content-Length计算错误可能导致服务器判定请求异常，提前关闭连接
3. 手动构造multipart请求的风险：手动处理请求体的拼接、流的写入很容易出错，比如刷新时机、缓冲区处理、流的交互细节里，可能藏着隐性的时序bug

已经试过的解决方案（均无效） #

• 预计算请求体总大小作为Content-Length，而且计算和实际写数据用的是同一套逻辑——但还是会间歇性触发Broken pipe
• 用try-with-resources语法确保所有流都被正确关闭
• 调整了连接超时和读取超时时间（运维告知服务器的读超时是30秒）

想请大家帮忙排查的方向 #

结合我手动构造multipart请求的实现，以及这个「要么写数据时断、要么拿响应时断」的间歇性Broken pipe问题，客户端侧可能存在哪些容易被忽略的问题？比如流的处理逻辑、Content-Length计算的隐性错误、线程安全问题，或者是HttpURLConnection的某些我没注意到的坑？

内容来源于stack exchange