Android调用springboot接口上传大字段，偶现接口超时的优化

介绍

最近有个功能，Android通过okhttp上传实体类，实体类包含一个大字段，上传的字符串长度达到300k，偶现接口超时的情况，大概100次有5次，看日志发现数据并没有到达接口，可能在网络传输中就超时了

优化1

​​直接接收对象：

    @ApiOperation(value = "插入主动测量记录")@PostMapping("/insertMeasureRecord")public Result insertMeasureRecord(@RequestBody LomeRingMeasureRecords lomeRingMeasureRecords ){return iRingAppService.insertMeasureRecord(lomeRingMeasureRecords);}

刚开始是这样接收的，后来优化成流式解析
流式解析：

  @Overridepublic Result insertMeasureRecordRequest(HttpServletRequest request) {// 1. 使用流式读取避免内存爆炸try (InputStream is = request.getInputStream();Reader reader = new InputStreamReader(is, StandardCharsets.UTF_8)) {// 2. 带超时的JSON解析CompletableFuture<LomeRingMeasureRecords> future = CompletableFuture.supplyAsync(() -> {return JSON.parseObject(reader, LomeRingMeasureRecords.class);});LomeRingMeasureRecords records = future.get(15, TimeUnit.SECONDS); // 15秒超时// 3. 继续原有处理逻辑return Result.ok(lomeRingMeasureRecordsService.insertMeasureRecords(records));} catch (TimeoutException e) {return Result.fail(ResultsCode.REQUEST_FAILED);} catch (Exception e) {return Result.fail(ResultsCode.REQUEST_FAILED);}}

优化2

即使修改成这样，还是偶现超时，所以对大字段进行了压缩，然后服务端进行解压
Android部分

public static Observable<JsonResult> insertMeasureRecord(String mac,String value,String testType,String filePath,String fileName,String label,String waveForm) {Log.i("waveForm size",waveForm.length()+"");String compressString="";try {compressString = DataCovertUtils.compressString(waveForm);} catch (IOException e) {e.printStackTrace();}Log.i("compressString size",compressString.length()+"");Map<String, Object> map = new HashMap<>();map.put("mac", mac);map.put("value", value);map.put("testType", testType);map.put("filePath", filePath);map.put("fileName", fileName);map.put("label", label);map.put("compressedWaveForm", compressString);return ServerAPIClient.getApi().insertMeasureRecord(map).subscribeOn(Schedulers.io()).unsubscribeOn(Schedulers.io()).observeOn(AndroidScheduler.mainThread());}

  // GZIP压缩字符串public  static String compressString(String str) throws IOException {if (str == null || str.isEmpty()) {return str;}ByteArrayOutputStream out = new ByteArrayOutputStream();try (GZIPOutputStream gzip = new GZIPOutputStream(out)) {gzip.write(str.getBytes(StandardCharsets.UTF_8));}return Base64.encodeToString(out.toByteArray(), Base64.NO_WRAP);}

然后springboot解压

 @Overridepublic Result insertMeasureRecordRequest(HttpServletRequest request) {try (InputStream is = request.getInputStream();Reader reader = new InputStreamReader(is, StandardCharsets.UTF_8)) {LomeRingMeasureRecords records = JSON.parseObject(reader, LomeRingMeasureRecords.class);// 解压处理if (records.getCompressedWaveForm() != null ) {try {String decompressed = decompressString(records.getCompressedWaveForm());records.setWaveForm(decompressed);} catch (IOException e) {// 解压失败记录日志，保持原数据log.error("解压waveForm失败", e);return Result.fail(ResultsCode.REQUEST_FAILED);}}return Result.ok(lomeRingMeasureRecordsService.insertMeasureRecords(records));} catch (Exception e) {log.error("处理测量记录请求失败", e);return Result.fail(ResultsCode.REQUEST_FAILED);}}// GZIP解压字符串private String decompressString(String compressedStr) throws IOException {if (compressedStr == null || compressedStr.isEmpty()) {return compressedStr;}byte[] compressed = Base64.getDecoder().decode(compressedStr);ByteArrayInputStream bis = new ByteArrayInputStream(compressed);GZIPInputStream gis = new GZIPInputStream(bis);// 使用ByteArrayOutputStream直接读取所有字节ByteArrayOutputStream baos = new ByteArrayOutputStream();byte[] buffer = new byte[1024];int len;while ((len = gis.read(buffer)) > 0) {baos.write(buffer, 0, len);}// 转换为字符串，保留原始换行符String result = baos.toString(StandardCharsets.UTF_8.name());gis.close();bis.close();baos.close();return result;}

这样原字段大概是300k，然后压缩完是55k，之前接口返回是3s，修改完是2.5s，因为涉及到python计算，没办法再提高了

疑问

按理说，字段没超过1M，不应该出现超时的情况，根本没有到达接口，可能还是网络问题

场景化建议

1. ​​推荐使用​直接接收对象的场景​​
   字段大小​​<1MB​​且结构固定（如普通表单数据）。
   需要快速开发，减少手动编码量。
   服务端内存充足（如JVM堆内存>2GB）。
2. ​​推荐使用流式解析的场景​​
   字段大小​​>10MB​​或包含压缩数据（如音频、视频、科学计算数据）。
   需要支持​​分片传输​​或​​断点续传​​（如大文件上传）。
   服务端内存受限（如云函数环境）

性能关键点分析

1. ​​数据解析性能​​
   ​​方式1（对象绑定）​​：
   依赖Jackson或Gson等库的优化解析，实测1MB JSON数据解析耗时约​​5-20ms​​（Spring Boot默认配置）。
   ​​瓶颈​​：大字段（如10MB+）可能导致堆内存压力和GC停顿。
   ​​方式2（流式解析）​​：
   使用BufferedReader逐行读取或JSONReader流式解析，1MB数据耗时约​​2-8ms​​（分块处理减少内存峰值）。
   ​​优势​​：避免一次性加载大对象到内存，适合处理​​压缩数据流​​或​​分片传输​​场景。
2. ​​内存与GC影响​​
   ​​方式1​​：
   若字段包含大文本或二进制数据（如压缩后的波形数据），可能直接导致​​堆内存溢出​​（默认堆大小约128MB-1GB）。
   ​​示例​​：10MB的compressedWaveForm字段会占用约​​20MB堆内存​​（含对象头和引用）。
   ​​方式2​​：
   流式处理可将内存占用控制在​​常量级别​​（如分块读取时每次仅加载64KB），适合处理​​超大数据流​​（如50MB+的压缩文件）
3. ​​压缩数据处理​​
   ​​方式1的缺陷​​：
   若字段已压缩（如GZIP），直接反序列化会触发​​二次解压​​（框架先解压到临时文件或内存，再解析JSON），导致​​CPU和内存双重消耗​​。
   ​​实测​​：10MB GZIP数据全量解压后约25MB，解析耗时增加50%。
   ​​方式2的优化​​：
   可在流式解析中​​直接处理压缩流​​（如GZIPInputStream），避免中间数据存储，节省50%以上CPU和内存。

性能测试数据参考