一种基于JDK原生改造的流式ZIP归档方法及系统与流程

本发明涉及java平台文件压缩、流式io与分布式云存储微服务，具体是一种基于jdk原生改造的流式zip归档方法及系统。

背景技术：

1、在云存储、微服务批量文件下载、在线归档、网关实时文件导出等线上业务场景中，系统需要对海量业务附件实时打包生成zip文件，并以网络流的形式直接对外输出，全程不得落地本地临时文件；同时该类场景普遍面临多重重叠的硬性约束，具体包括容器内存配额严格受限，禁止一次性加载全量文件至内存；单次打包的文件数量可达上万，业务附件大量存在同名文件，直接覆盖会造成业务数据丢失；单源文件大小普遍超过4gb，传统zip标准无法承载；集群cpu资源紧张，不允许压缩运算消耗过多算力，要求具备较高的打包吞吐能力。

2、现有java原生zip工具与第三方压缩库均无法同时满足上述全部复合约束，其中原生java zipoutputstream存在多处固有缺陷：默认采用deflated压缩模式，高并发归并打包场景下cpu占用较高、打包速度较慢；批量归并打包时同名文件直接覆盖，无自动化冲突规避逻辑，存在业务数据丢失风险；切换为stored存储模式时，底层强制要求预先读取完整文件长度与crc校验值，无法实现边读边写的纯流式输出；对4gb以上超大文件的zip64扩展支持繁琐，需要开发者手动判断文件尺寸、手动写入扩展头部，流式场景下极易出现内存溢出、打包包体损坏的问题。而zip4j、apache commons compress等第三方开源方案同样存在短板：引入第三方jar包会增加项目体积，易引发版本依赖冲突与安全漏洞风险；绝大多数实现依赖本地磁盘临时文件中转，不符合无盘容器的纯流式架构要求；缺少面向批量归并场景的stored存储模式一体化适配，多特征组合后易产生解压失败、内存溢出的问题；此外，stored存储模式、数据描述符、管道流、zip64扩展、重名校验虽均为本领域公知技术，但将多项技术同时叠加应用于纯流式归并打包场景时，现有公开方案存在底层协议与代码逻辑层面的适配冲突，本领域技术人员仅通过简单叠加公知技术，无法生成可用、标准和稳定的流式打包工具。

3、因此，针对以上现状，迫切需要开发一种基于jdk原生改造的流式zip归档方法及系统，以克服当前实际应用中的不足。

技术实现思路

1、本发明的目的在于提供一种基于jdk原生改造的流式zip归档方法及系统，以解决上述背景技术中提出的问题。

2、为实现上述目的，本发明提供如下技术方案：

3、一种基于jdk原生改造的流式zip归档系统，包括增强型zipoutputstream与filepackhandler打包处理器；

4、所述增强型zipoutputstream继承自jdk原生zipoutputstream类，重构原生条目校验逻辑以实现stored存储模式与后置数据描述符的兼容，内置文件名冲突自动处理机制，支持zip64扩展的自动适配；

5、所述filepackhandler打包处理器基于java管道流构建异步生产消费模型，以所述增强型zipoutputstream作为数据生产端执行打包逻辑，对外输出标准zip输入流，全程无本地临时文件落地。

6、作为本发明进一步的方案：所述增强型zipoutputstream通过重构putnextentry方法与closeentry方法的逻辑实现stored存储模式与后置数据描述符的兼容：

7、写入条目头部前，强制将条目的压缩方法设置为stored，将通用目的位标志设置为后置数据描述符对应的标识值，并将条目的未压缩大小、压缩后大小与crc校验值初始化为0；

8、数据写入过程中，实时累计文件字节数并更新crc校验值；

9、关闭条目时，绕过原生参数完整性校验，将实时统计得到的文件尺寸与crc校验值写入后置数据描述符。

10、作为本发明进一步的方案：所述增强型zipoutputstream维护有并发安全的已写入文件名集合，并通过handlename重名处理方法实现文件名冲突自动处理；

11、所述handlename重名处理方法被配置为：当检测到文件名冲突时，在原文件名基础上按预设规则追加序号生成新文件名，重复校验直至生成全局唯一的条目名称。

12、作为本发明进一步的方案：所述增强型zipoutputstream的zip64扩展自动适配逻辑包括：

13、写入本地文件头时，统一在条目扩展字段区预分配固定长度zip64扩展占位位，全程无需提前读取、预判源文件整体尺寸；

14、关闭条目时，实时汇总本条条目累计字节总量，对比4gb尺寸阈值动态判断：若单文件未压缩大小超4gb，则向预先预留的扩展占位区回填8字节高精度尺寸字段；若文件尺寸未达到阈值，直接保留预留占位空间并填充zip标准空占位标识，不破坏本地文件头固定长度结构；

15、写入中央目录阶段，根据单文件尺寸、条目总数与中央目录总大小，自动生成对应的zip64扩展结构。

16、作为本发明进一步的方案：所述filepackhandler打包处理器包括配对连接的管道输入流、管道输出流以及业务线程池；

17、所述业务线程池用于异步执行打包任务，驱动所述增强型zipoutputstream将zip数据持续写入所述管道输出流；

18、所述管道输入流作为对外统一接口，用于向下游业务输出zip二进制数据流。

19、一种基于jdk原生改造的流式zip归档方法，包括以下步骤：

20、构建基于管道流的异步生产消费模型，将基于jdk原生zipoutputstream改造得到的增强型zipoutputstream作为生产端，以管道输入流作为消费端对外输出数据流；

21、采用stored无压缩存储模式，通过后置数据描述符承载文件尺寸与crc校验信息，实现边读边写的流式条目写入；

22、条目写入过程中自动检测文件名冲突，生成全局唯一的条目名称；

23、打包收尾阶段自动适配zip64扩展，输出符合标准格式的zip归档文件流。

24、作为本发明进一步的方案：所述流式条目写入的过程具体包括：

25、写入条目头部前，强制将条目的压缩方法设置为stored，设置后置数据描述符标识，并将文件尺寸与crc校验值初始化为0；

26、分段写入文件数据的过程中，实时累计文件字节数并更新crc校验值；

27、当前条目数据写入完成后，关闭条目并将实时统计得到的文件尺寸与crc校验值写入后置数据描述符。

28、作为本发明进一步的方案：所述自动检测文件名冲突的过程具体包括：

29、维护已写入文件名集合，每次写入条目前校验当前文件名是否已存在于集合中；

30、若检测到文件名冲突，则在原文件名基础上按预设规则追加序号生成新文件名，重复校验直至生成全局唯一的条目名称后加入集合。

31、作为本发明进一步的方案：所述自动适配zip64扩展的过程具体包括：

32、写入本地文件头时统一在条目扩展字段区预分配固定长度zip64扩展占位位，全程无需提前读取、预判源文件整体尺寸，条目写入完成关闭条目时，实时汇总本条条目累计字节总量，对比4gb尺寸阈值动态判断：若单文件未压缩大小超4gb，则向预先预留的扩展占位区回填8字节高精度尺寸字段；若文件尺寸未达到阈值，直接保留预留占位空间并填充zip标准空占位标识，不破坏本地文件头固定长度结构；

33、全部条目处理完成后，根据单文件尺寸、条目总数与中央目录总大小，自动写入对应的zip64扩展结构。

34、作为本发明进一步的方案：所述异步生产消费模型的运行过程包括：

35、将打包任务提交至业务线程池异步执行，由增强型zipoutputstream持续向管道输出流写入zip数据；

36、消费端从管道输入流中持续读取zip二进制数据流并交付下游业务；

37、当打包线程发生异常时，采用分层异常传播与闭环资源回收逻辑处理：

38、在异步打包生产线程内设置全局捕获块拦截全类型运行异常，执行管道输出流的带异常重载关闭方法，将原始异常对象完整绑定至管道输出流并关闭流句柄，使消费端读取时直接抛出携带完整堆栈的原始异常；

39、按从内到外的顺序逆向释放全部io资源，依次关闭增强型zipoutputstream、源文件读取输入流、管道输出流，并标记处理器状态为异常终止；

40、通过流关闭动作唤醒因管道缓冲区满而阻塞的消费端线程，同步清理所有已打开的流资源。

41、与现有技术相比，本发明的有益效果是：

42、强制采用stored无压缩归档模式，去除deflated压缩运算环节，打包速度得到显著提升，cpu峰值占用大幅下降，能够适配集群cpu资源紧张的应用场景；

43、增强型zipoutputstream完全基于jdk原生类改造实现，不引入外部jar包，可规避版本冲突、开源漏洞、第三方库兼容等问题，适配全系列jdk运行环境；

44、filepackhandler打包处理器采用双管道异步生产消费模型，全程不生成临时文件，能够适配无盘容器、serverless、对象存储在线归档等场景；

45、增强型zipoutputstream内置并发安全的自动重命名逻辑，批量归并打包时可彻底杜绝同名文件覆盖丢失的问题，保障业务数据完整性；

46、跨平台标准兼容性好：输出标准zip/zip64格式的压缩包，windows、macos、linux及移动端解压工具均可正常打开，采用utf-8编码的中文文件名无乱码；

47、采用分段流式读写方式，内存占用与单文件大小无关，可自动适配4gb以上超大文件，上万文件批量打包无内存溢出风险；

48、通过filepackhandler打包处理器统一封装并对外暴露标准流式输入流，可直接对接http下载、对象存储上传和微服务网关等场景，能够快速集成至各类文件导出业务中。