[Product manager face to face] 内存吃满之后,连任务管理器都打不开?内存救生筏想请大家先试试
Tofloor
poster avatar
crowiiing
deepin product team
2026-10-10 16:07
Author

各位大佬、deepiner,好久不见。

今天来发个还在打磨的小东西,想请大家先试试。

系统要求:deepin 25,需系统更新至 DTK6 ≥ 6.7.47

先说它想解决的问题

内存被吃满的时候,最难受的其实不是"某个应用被杀了",而是——整个桌面都动不了。

鼠标还能移,但任务栏点不动,任务管理器打不开,想结束个进程都找不到入口。明明只是想杀掉那个吃内存的,结果连"杀"这个动作都做不了。最后只能长按电源键。

我们想解决的就是这个:在系统被拖死之前先介入,让你始终还有得操作。

弹窗大概长这样:

内存救生筏_界面图合集_2026-10-10.png

它做什么

平时它什么都不干,就在后台盯着内存压力。触发条件是定死的:

  • 内存压力:内核 PSI full avg10 连续 20 秒超过 50%,且过去 30 秒内确实发生过内存回收——不是"内存少了",是"已经在卡了"
  • 内存 + swap 双高:两者同时超过 90%

一旦触发,它会把最占内存的几个应用原地冻住(最多 3 个)。

冻住不是杀。进程停在那里,内存还在,数据没丢。但它不再跟别的程序抢资源了,系统重新有空余去响应你。

然后弹个窗,告诉你冻了谁,以及当前的内存和交换空间情况。你可以选:

  • 恢复 —— 解冻,应用接着跑,像什么都没发生
  • 强制结束 —— 真正释放内存,不可逆

它也不会一直弹。 你处理完之后,它会安静 15 秒才可能再弹一次。刚点完「恢复」下一轮又糊上来,那就不是帮忙是添乱了。

还有一个点很关键:任务栏、锁屏这些核心组件在保护名单里,永远不会被冻,也不会出现在弹窗里。 目的就是保证你任何时候都还能操作桌面。

为什么叫"救生筏"

Apple 内核里那个"内存耗尽就杀进程"的机制叫 Jetsam,是个航海术语,意思是**"为了保住船,把货扔下海"**。名字本身就说明了逻辑:弃货保船,不可逆。

我们想反过来:不扔东西,先兜住,随时能回来。

为什么是"冻住",而不是直接杀

因为直接杀有两个问题。

一是它不会问你。内核的 OOM Killer 挑一个进程就杀掉,那个进程未必是你要牺牲的那个,没保存的东西也一并没了。

二是杀了也未必救得回来。内存是释放了,但你手上正在做的事已经被打断,损失已经造成。

冻住不一样:先把系统从"动不了"拉回"能操作",再把决定权交给你。你确认了,才动真的。

怎么装

下载:

deepin-liferaft-0.2.0.zip

解压出来有两个 deb:主包 + 调试符号包(dbgsym)。一条命令一起装,apt 会自动处理两者的依赖顺序:

bash

sudo apt install ./deepin-liferaft_0.2.0_amd64.deb ./deepin-liferaft-dbgsym_0.2.0_amd64.deb

第二个是调试符号,装上之后万一程序崩了,堆栈能带出函数名。测试期建议一起装——只有一串地址的崩溃报告,我们很难查。

装完一定要重启一次。它靠内核的 PSI 判断内存压力,而部分 deepin 内核默认把它关着、运行时还开不了,只能从启动参数里开——安装包已经自动帮你加好了,重启即生效。

重启后确认服务起来了:

bash

systemctl --user status deepin-liferaft.service

看到 Active: active (running) 就说明装好了。

想看它实时在干什么(触发、冻结、恢复都有日志):

bash

journalctl --user -u deepin-liferaft.service -f

想主动试出弹窗

正常使用可能很难把内存压满,可以主动造点压力:

bash

sudo apt install stress-ng
stress-ng --vm 2 --vm-bytes 80% --vm-keep --timeout 120s

这会把机器真的搞卡,试之前先保存好手头的工作。压力上来之后,看它冻的对不对、弹窗出来的时候你还能不能正常操作——这正是我们最想知道的。

停用和卸载

临时停一次(下次登录还会启动):

bash

systemctl --user stop deepin-liferaft.service

长期停用(服务是安装包里全局启用的,普通 disable 盖不住,得用 mask):

bash

systemctl --user mask --now deepin-liferaft.service
# 想恢复:
systemctl --user unmask deepin-liferaft.service
systemctl --user start deepin-liferaft.service

彻底卸载:

bash

sudo apt purge deepin-liferaft
sudo update-grub   # 去掉安装时加的 psi=1 启动参数;留着其实也无害

最后

别装在唯一的生产力机器上。 它会冻你的应用,虽然设计上可逆,但数据无价;如果误操作「强制结束」是真的不可逆。

用下来有什么想说的,回帖就行——最好附上一段触发前后的日志(journalctl --user -u deepin-liferaft.service),比单说"卡/不卡"有用得多。

尤其是这一点:内存压满的时候,它到底有没有让你重新拿回操作? 这是这个功能成不成立的关键,也是我们最没底的地方——我们自己的测试数据说明不了太多。

——

叠个甲:这是还在打磨的版本,肯定还有我们没发现的问题。

哪里好用可以夸,哪里反人类欢迎喷。

Reply Favorite View the author
All Replies
2 / 2
To page
avatar
zccrs
deepin
2026-10-14 17:33
#21
bg:

系统真正需要的是优化,是内存占满系统卡死后任务管理器依然能打开。而不是又捣鼓出一个什么救生筏。

这是两码事,系统再优化也有内存占满的时候,就算系统占用内存为0,应用也可能把内存占满,这时候就需要一个兜底的方案。

Reply View the author
avatar
bg
deepin
2026-10-15 09:45
#22
zccrs:

这是两码事,系统再优化也有内存占满的时候,就算系统占用内存为0,应用也可能把内存占满,这时候就需要一个兜底的方案。

你告诉我,哪个操作系统,哪个linux发行版,有单独搞出来一个软件解决内存占满的场景?

Reply View the author
avatar
方老四
deepin
2026-10-16 10:10
#23

这是操作系统本身应该解决的问题吧

Reply View the author
2 / 2
To page