框架学习四-1:处理OOM之LazyList

本文介绍了一种简洁的异步图片下载方法,图片保存于内存和SD卡,适用于2.0及以上版本。使用步骤包括定义ImageLoader实例、调用DisplayImage方法显示图片,并在完成后清理缓存。确保项目中只创建一个ImageLoader实例以优化图像缓存效率。请添加网络权限和读取SD卡权限。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、简介

异步下载图片,图片保存在内存和SD卡中。

优点:简洁,用起来方便。

缺点:貌似不更新了。也不算缺点。

二、地址和支持的版本

下载地址:https://github.com/thest1/LazyList

再贴个地址:http://download.csdn.net/detail/mwj_88/7964883

支持版本:2.0+

三、用法

定义一个ImageLoader实例,然后调用其DisplayImage()即可,最后记得清除缓存。

ImageLoader imageLoader=new ImageLoader(context);
...
imageLoader.DisplayImage(url, imageView);

imageLoader.clearCache();

网络权限和读取SD卡权限:

<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
注意:一个项目中仅创建一个ImageLoader实例,这样的图像缓存将更有效。

OK ] Stopped Network Name Resolution. Starting Network Name Resolution... [ 229.126832] Out of memory: Killed process 701 (systemd-udevd) total-vm:20340kB, anon-rss:2044kB, file-rss:1228kB, shmem-rss:0kB, UID:0 pgtables:60kB oom_score_adj:0 [ OK ] Started Network Name Resolution. [ 235.400261] Out of memory: Killed process 770 (systemd-resolve) total-vm:25364kB, anon-rss:4868kB, file-rss:1432kB, shmem-rss:0kB, UID:101 pgtables:92kB oom_score_adj:0 [ OK ] Stopped Network Name Resolution. [ 236.394466] Out of memory: Killed process 787 (systemd-udevd) total-vm:20340kB, anon-rss:2044kB, file-rss:1164kB, shmem-rss:0kB, UID:0 pgtables:60kB oom_score_adj:0 [ 236.514772] Out of memory: Killed process 772 (systemd-udevd) total-vm:20340kB, anon-rss:2044kB, file-rss:1124kB, shmem-rss:0kB, UID:0 pgtables:60kB oom_score_adj:0 [ 236.526228] Out of memory: Killed process 775 (systemd-udevd) total-vm:20340kB, anon-rss:2044kB, file-rss:1120kB, shmem-rss:0kB, UID:0 pgtables:60kB oom_score_adj:0 [ 236.797549] Out of memory: Killed process 783 (systemd-udevd) total-vm:20340kB, anon-rss:2044kB, file-rss:1120kB, shmem-rss:0kB, UID:0 pgtables:60kB oom_score_adj:0 [ 236.828648] Out of memory: Killed process 784 (systemd-udevd) total-vm:20340kB, anon-rss:2044kB, file-rss:1096kB, shmem-rss:0kB, UID:0 pgtables:60kB oom_score_adj:0 [ 238.501088] Out of memory: Killed process 788 ((resolved)) total-vm:167744kB, anon-rss:2740kB, file-rss:1268kB, shmem-rss:0kB, UID:0 pgtables:88kB oom_score_adj:0 Starting Network Name Resolution... [FAILED] Failed to start Network Name Resolution. See 'systemctl status systemd-resolved.service' for details. [ OK ] Stopped Network Name Resolution. Starting Network Name Resolution... [ 240.112752] Out of memory: Killed process 791 ((resolved)) total-vm:167784kB, anon-rss:2740kB, file-rss:1456kB, shmem-rss:0kB, UID:0 pgtables:88kB oom_score_adj:0 [FAILED] Failed to start Network Name Resolution. See 'systemctl status sys
最新发布
07-21
<think>嗯,用户提出了一个关于systemd-resolved服务启动失败的问题,原因是内存不足。这个问题涉及Linux系统服务管理和资源优化,需要分步骤排查。 首先需要确认用户的具体环境。systemd-resolved是Linux系统负责DNS解析的核心服务,它的崩溃会导致整个系统的域名解析失效。内存不足可能是真实物理内存耗尽,也可能是cgroup限制造成的。 从引用内容来看[^2],systemd服务启动时有TimeoutStartSec配置,如果服务未在规定时间内完成启动就会被终止。而内存不足可能导致systemd-resolved在启动过程中超时。不过更可能的情况是服务进程因OOM直接被内核杀死。 用户可能已经观察到类似"cannot allocate memory"的日志。需要引导用户检查几个关键点:首先是系统整体内存使用情况,通过free -h查看;其次是服务自身的cgroup内存限制,这在systemd服务文件中配置;最后是内核日志中的OOM记录。 解决方法需要分层处理:如果是全局内存紧张,需要优化应用或扩容;如果是cgroup限制过小,可以调整MemoryLimit配置;还可以尝试优化systemd-resolved本身,比如减少并发连接数。 特别要注意引用[1]提到的EXTEND_TIMEOUT_USEC机制,如果服务能主动申请延长时间,可能避免因初始化慢导致的误判。不过systemd-resolved是否支持这个特性需要查证。 用户可能还隐藏着其他需求,比如希望服务能快速恢复运行。因此除了解决根本原因,也可以考虑配置自动重启策略,引用[3]提到systemd默认会发送SIGTERM和SIGKILL,我们可以调整Restart和RestartSec参数。 最后生成的问题要围绕服务调优展开,因为用户明显是系统管理员角色,需要进阶的故障排查和性能优化知识。特别是要突出systemd特有的配置技巧,比如切片管理和内存压测工具的使用。</think>针对 systemd-resolved 服务因内存不足启动失败的问题,请按以下步骤排查解决: --- ### 一、确认内存不足原因 1. **检查系统内存状态** ```bash free -h # 查看总内存/交换空间 cat /proc/meminfo # 详细内存信息 dmesg | grep -i oom # 搜索内核OOM日志 ``` - 若存在 `Out of memory: Kill process` 且涉及 `systemd-resolved`,说明被内核强制终止。 2. **检查服务限制** ```bash systemctl show systemd-resolved | grep Memory ``` - 若输出类似 `MemoryMax=50M`,说明服务被cgroup限制了内存。 --- ### 二、解决方案 #### 方案1:扩大服务内存限制(推荐) 1. 创建覆盖配置: ```bash sudo mkdir -p /etc/systemd/system/systemd-resolved.service.d/ sudo nano /etc/systemd/system/systemd-resolved.service.d/override.conf ``` 2. 增加内存限制: ```ini [Service] MemoryMax=100M # 提升至100MB(根据实际调整) MemoryHigh=80M # 软限制阈值 ``` 3. 重载配置并重启服务: ```bash sudo systemctl daemon-reload sudo systemctl restart systemd-resolved ``` #### 方案2:优化系统内存 - **释放内存** ```bash sync; echo 3 > /proc/sys/vm/drop_caches # 清理缓存(临时方案) ``` - **增加交换空间** ```bash sudo fallocate -l 1G /swapfile # 创建1GB交换文件 sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile sudo echo '/swapfile none swap sw 0 0' >> /etc/fstab # 永久生效 ``` #### 方案3:降低服务负载 1. 减少并发DNS请求: ```bash sudo nano /etc/systemd/resolved.conf ``` 修改配置: ```ini [Resolve] DNS=8.8.8.8 1.1.1.1 # 指定稳定DNS Cache=yes # 启用缓存 DNSStubListener=yes # 轻量监听模式 ``` 2. 重启服务: ```bash sudo systemctl restart systemd-resolved ``` --- ### 三、验证修复 ```bash systemctl status systemd-resolved # 检查状态 journalctl -u systemd-resolved -f # 实时跟踪日志 cat /sys/fs/cgroup/system.slice/systemd-resolved.service/memory.current # 查看实时内存 ``` --- ### 关键机制说明 1. **启动超时控制** 若服务启动时内存不足导致初始化缓慢,可能触发 `TimeoutStartSec=` 限制(默认值参见 `systemd-system.conf` [^2])。需确保服务在超时前完成启动或通过 `EXTEND_TIMEOUT_USEC=` 申请延长时间[^1]。 2. **资源隔离** systemd 通过 cgroups 限制服务资源,内存超限会触发 OOM Killer。调整 `MemoryMax=` 可避免服务被误杀[^3]。 --- ### 相关问题 1. 如何诊断 systemd 服务的 cgroup 内存泄漏? 2. systemd-resolved 的 `Cache=` 和 `DNSStubListener=` 配置有何优化技巧? 3. 除内存限制外,哪些 systemd 参数可防止服务崩溃(如 `Restart=`, `RestartSec=`)? [^1]: 引用自 systemd 文档:通过 `EXTEND_TIMEOUT_USEC` 可延长服务启动时间 [^2]: `TimeoutStartSec=` 默认值继承自 `/etc/systemd/system.conf` 中的 `DefaultTimeoutStartSec` [^3]: 当服务未指定 `ExecStop=` 时,systemd 默认发送 SIGTERM 和 SIGKILL 终止进程
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值