jlink 选项压缩有什么作用?

Question

jlink 压缩选项有什么作用？ Oracle 文档对此不是很详细：

Enable compression of resources:
0: No compression
1: Constant string sharing
2: ZIP

压缩的资源是什么？--compress=2有什么缺点吗？

Answer 1

--compress=2有什么缺点吗

我不知道compress=2如何在内部压缩模块，或者确切地说哪些模块要精确地压缩，但我发现了这个与性能相关的错误

性能数据/影响，供用户确定应选择哪种jlink优化

--

strip-debug 在 JRE 映像的构建中默认启用，并将运行时映像(lib/模块)的大小减小 ~20% (130M -> 106M)，而对启动没有影响

--compress=0 将 lib/modules 的大小降低了 ~30%(106M -> 69.5M)，实际上似乎有利于简单测试中的启动(Hello World 的 ~8 毫秒改进)。

--compress=1 将 lib/模块的大小降低 ~54% (106M -> 49M)，但会给启动带来惩罚(在 Hello World 上减速 ~8 毫秒)

--compress=2 将 lib/模块的大小降低 ~53% (106M -> 49.5M)，但对启动的惩罚更大(Hello World 的 ~13ms 减速)

在我看来，--compress的数字级参数是违反直觉的，也许应该明确地调用(--compress=strings，--compress=zip)。由于两种不同的压缩策略似乎相互对抗，因此似乎它们甚至应该相互排斥(删除 --compress=2)。

--compress=0 在改善启动和静态占用空间之间取得平衡，--compress=1 以很小的启动时间损失最小化静态占用空间。

Answer 2

这纯粹是基于观察。 我很想看到一个更权威的答案。

结果图像中的lib/modules文件(即应用程序模块的二进制合并)似乎是被压缩的内容。 我不知道该文件的实际格式是什么。

我从未观察到使用--compress=2的任何问题。