高负载下Cosmos DB中GZIP+Base64编码XML解压OOM及乱码排查

核心错误：解码解压逻辑的数据流与变量错误 #

你的解码代码存在两个致命问题，直接导致乱码、数据膨胀和OOM：

1. 错误使用原始输入流
   解码后的GZIP压缩数据存储在decodebase64变量中，但创建ByteArrayInputStream时却传入了原始的arr（Base64编码后的字节数据）。这意味着GZIPInputStream尝试解压的是Base64文本而非合法的GZIP压缩字节流。

   • 非生产环境数据量小或负载低时，可能巧合触发IO异常被捕获，但高负载下，GZIPInputStream会尝试读取大量无效数据，导致解码出的内容全是乱码（�），且数据量异常膨胀至GB级，最终引发OOM。

2. 变量名遮蔽导致数据未正确赋值
   try块内用var gzip定义了GZIPInputStream实例，遮蔽了外部的byte[] gzip变量。执行gzip = gzip.readAllBytes()时，实际是将读取的字节赋值给内部的GZIPInputStream变量（编译时会报错，除非代码存在笔误），外部的byte[] gzip始终未被正确赋值，最终返回的字符串要么基于未初始化的数组，要么读取了错误的无效数据。

次要问题：编码逻辑的冗余操作 #

编码逻辑中手动调用gzipOut.close()属于冗余操作，因为GZIPOutputStream被包含在try-with-resources中，会自动关闭资源。不过这不是引发当前故障的直接原因。

高负载场景的放大效应 #

在高负载更新场景下，Cosmos DB的文档更新可能出现偶发的部分数据写入异常（如字节截断），但解码逻辑本身的错误会将这些小异常放大为大规模的乱码和OOM。非生产环境负载低，这类问题难以复现。

内容的提问来源于stack exchange，提问作者Rajat Somani