结合你的配置（16GB内存、11代Intel Core i7 4物理核）和已经做的尝试（调整-j参数、降低CPU主频），我整理了几个针对性的排查方向和解决方案：

• 检查内存与交换空间占用
  虽然16GB内存看起来充足，但大型项目编译时可能瞬间耗尽内存，触发OOM（内存不足）导致系统无响应。你可以在编译时用htop或top实时监控内存使用率；另外用free -h查看交换空间大小，如果swap不足，可临时创建一个交换文件缓解：

  sudo fallocate -l 2G /swapfile
  sudo chmod 600 /swapfile
  sudo mkswap /swapfile
  sudo swapon /swapfile
  

  编译完成后可以用sudo swapoff /swapfile关闭临时swap，若有效可配置永久swap。

• 调整GCC版本与编译优化参数
  GCC 10.0.3对11代酷睿的指令集支持可能不够完善，建议尝试升级到更稳定的GCC 11（Ubuntu 20.04可通过apt install gcc-11安装，再用update-alternatives切换默认版本）。另外，若CMake中启用了-O3激进优化，可降级为-O2，同时添加-march=native参数确保编译适配你的CPU架构，减少指令集不兼容导致的异常。

• 升级系统内核与Intel微码
  Ubuntu 20.04默认的5.4内核对11代酷睿的支持有限，建议升级到5.15 LTS内核：

  sudo apt install linux-generic-hwe-20.04
  

  同时安装Intel微码更新修复CPU底层bug：

  sudo apt install intel-microcode
  

  完成后重启系统再尝试编译。

• 限制编译进程的资源优先级
  除了调整-j参数，还可以降低编译进程的优先级，给系统留足响应空间：

  nice -n 10 cmake --build . -j4
  

  也可以直接限制编译进程的内存上限，避免内存耗尽：

  systemd-run --user --property MemoryMax=12G cmake --build . -j4
  

• 通过系统日志定位根本原因
  系统死机重启后，用journalctl -b -1查看上一次启动的完整日志，重点关注死机前的内核报错（比如OOM Killer的触发记录、CPU硬件相关的错误）；也可以用dmesg查看内核缓冲区信息，帮你确认是内存、CPU还是驱动层面的问题。

内容的提问来源于stack exchange，提问作者Artem Karpov