多线程解压安装ZIP，EXE分析-微软的MSI安装包和 .NET SDK EXE

微软的 MSI 安装包和 .NET SDK EXE 安装程序在解压 / 安装阶段的线程策略有明确的设计逻辑，但并非简单的 "无差别多线程解压"，而是结合安装包类型、资源依赖和系统兼容性做了分层优化。以下是具体分析：

安装包类型	是否采用多线程解压？	核心策略
MSI 安装包	否（核心阶段单线程）	解压 / 文件复制以 "组件 / 功能" 为单位串行执行，仅辅助任务（如注册表 / 服务）并行
.NET SDK EXE	是（有限多线程）	自解压阶段采用多线程分块解压，安装阶段混合串行 + 并行

MSI 是微软的标准安装格式（基于 Windows Installer 引擎），其设计核心是事务性、可回滚，而非 "极致解压速度"，因此解压逻辑有严格的串行约束：

解压阶段（FileCopy 动作） ：MSI 中的文件（包括压缩的 DLL/EXE）存储在 CAB 压缩包中，Windows Installer 引擎默认单线程逐文件解压 （按组件 / 文件表顺序）。原因是：
- MSI 需保证文件版本、覆盖规则、权限的严格顺序（比如先解压依赖 DLL，再解压主程序）；
- 事务性要求：若解压中断，需精准回滚，多线程会导致回滚逻辑复杂度指数级上升；
- 历史兼容性：需适配老旧系统（如 Windows 7），避免多线程引发的资源竞争。
并行优化点：仅在 "非核心步骤"（如注册表写入、服务注册、快捷方式创建）中，Windows Installer 会通过 "并发动作"（Concurrent Actions）少量并行，但这并非解压环节。

.NET SDK 的 EXE 是自解压引导程序（Bootstrapper），微软对其做了性能优化，核心逻辑分为两步：

第一步：自解压阶段（多线程） EXE 内置的压缩包（包含 SDK 核心文件、运行时、依赖）采用 分块压缩 + 多线程解压 ：
- 底层依赖微软的 LZMA/Deflate 变种压缩算法，将大文件拆分为多个块；
- 解压时启动 2-4 个线程（根据 CPU 核心数动态调整，默认不超过逻辑核心数的 50%）并行解压不同块；
- 目标：减少大文件（如 dotnet.runtime.dll、SDK 工具集）的解压耗时。
第二步：安装阶段（串行 + 并行） 解压完成后，安装逻辑分为：
- 串行部分：核心文件注册、GAC 安装、环境变量写入（需顺序执行）；
- 并行部分：多个独立组件（如 ASP.NET Core 运行时、SDK 工具集）的注册表 / 配置写入并行执行。

即使 .NET SDK 支持多线程解压，微软也不会无限制开线程，核心原因：

I/O 瓶颈：解压的核心瓶颈是磁盘 I/O（尤其是机械硬盘），超过 CPU 核心数的线程会导致磁盘寻道竞争，反而降低速度；
系统兼容性：需适配低配设备（如单核 / 双核老电脑），避免多线程导致的高内存占用、系统卡顿；
压缩格式限制：CAB（MSI 用）、LZMA（.NET SDK 用）的压缩结构决定了 "分块并行" 是上限，无法做到 "单文件多线程解压"（除非文件本身分块）；
依赖约束：部分 DLL 需按顺序注册（如先装 runtime，再装 SDK），多线程会破坏依赖链。

若想直观确认，可通过工具监控：

MSI 安装 ：用 Process Monitor 过滤 msiexec.exe 的 File Read/Write 操作，可见文件解压按顺序执行，线程数稳定在 1-2；
.NET SDK EXE 安装 ：用 Task Manager 查看 dotnet-sdk-xxx.exe 的线程数，解压阶段线程数会升至 4-8，安装阶段回落。