在Java应用中,内存缓存是提升性能的关键策略。然而,缓存数据丢失却是一个常见问题。本文将通过一个案例分析,深入探讨导致Java缓存数据无法获取的根本原因,并提供有效的优化方案。
案例背景:
一个项目使用名为scenarioBuffer的类,将约16万条asset数据缓存到HashMap中。scenarioBuffer类使用了@Component注解,并提供静态方法getBAsset用于数据获取。应用启动时,scenarioBuffer通过ApplicationRunner接口初始化缓存。然而,运行过程中,getBAsset方法频繁返回空值。更令人困惑的是,服务器内存告急(可用内存仅剩100MB,缓存占用3GB,总内存8GB),重启服务器并清除缓存后,问题暂时解决。
立即学习“Java免费学习笔记(深入)”;
问题根源分析:
尽管为tomcat分配了约3GB内存,服务器内存不足仍然是主要问题。内存不足时,jvm会触发垃圾回收,甚至强制关闭进程释放内存,导致缓存数据被清除。
代码缺陷:
原代码存在以下问题:
- 静态方法与单例: scenarioBuffer类使用了静态方法getBAsset和静态变量assetBuffer,以及getInstance()方法。在spring管理的Bean中,这完全没有必要。spring容器本身管理Bean的单例,静态方法和变量增加了代码复杂度,也难以进行单元测试。
- 依赖注入缺失: 获取scenarioBuffer实例没有使用Spring的依赖注入,而是使用了getInstance()方法,降低了代码的可维护性和可测试性。
- 初始化方法: 使用ApplicationRunner初始化缓存虽然可行,但@PostConstruct注解或InitializingBean接口更清晰、易于理解。
优化方案:
建议采用Spring的依赖注入和@PostConstruct注解优化代码:
修改后的scenarioBuffer类:
@Component public class scenarioBuffer implements IActionListener { @Autowired private IAssetService assetService; private Map<String, List<Asset>> assetBuffer = new HashMap<>(); @PostConstruct public void init() { List<Asset> assetList = assetService.list(); assetBuffer.put("key", assetList); // 此处需根据实际情况修改key } public List<Asset> getBAsset(String groupId) { return assetBuffer.get(groupId); } }
在需要使用缓存的类中,通过@Autowired注入scenarioBuffer实例:
@Service public class XxxService { @Autowired private ScenarioBuffer scenarioBuffer; public void xxx() { List<Asset> asset = scenarioBuffer.getBAsset("xxx"); // 此处需根据实际情况修改groupId // ... } }
这些修改使代码更简洁、易于维护和测试,并避免了静态方法和变量带来的问题。
此外,需要关注服务器内存使用情况。如果内存经常不足,则需考虑增加服务器内存或优化程序以减少内存占用。虽然案例中暂时不考虑redis,但长期来看,使用Redis等分布式缓存能有效缓解内存压力并提升性能。