共计 1086 个字符,预计需要花费 3 分钟才能阅读完成。
一、引言来
零碎中时常要对外裸露一些非凡数据,这些数据存储于关系型数据库中,且显著的特色是:
- 数据申请频繁
- 数据变动很小
- 数据体量略大
数据申请频繁,阐明要频繁的与数据库产生交互,占用与数据库的会话资源。而且数据量体量略大,又须要大量应用数据传输过程的通道。数据变动很小,说数据简直是静态数据。
一般来说,遇到这样的场景咱们会想到上缓存,例如 Redis
,Memcached
,Caffeine
。然而本着 能不引入,简略最好 的准则,我便尝试应用 Java 的动态变量实现了一个繁难的“缓存”。
二、实现来
具体实现如下代码,过程中应用了static
,AtomicReference
,SoftReference
。
public class DictService {static final AtomicReference<SoftReference<DictRegionDTO>> regionCache = new AtomicReference<>();
/**
* fetch all of region
* @return region all
*/
public Optional<DictRegionDTO> fetchRegion(){if(regionCache.get() !=null && regionCache.get().get() !=null ){return Optional.ofNullable(regionCache.get().get());
}
//todo fetch by repository,return @NotNull value
final DictRegionDTO dictRegionDTO = new DictRegionDTO(new ArrayList<>());
regionCache.set(new SoftReference<>(dictRegionDTO));
return Optional.of(dictRegionDTO);
}
}
static
,保障此变量全局共享。补充阐明JDK8
当前动态变量存储在JVM
的堆上。
AtomicReference
保障多线程环境下应用变量时候是原子操作,实现对象援用的原子更新。
SoftReference
即对象的软援用,如果一个对象具备软援用,且内存空间足够,GC
就不会回收它;如果内存空间有余了,GC
就会回收这些对象的内存。
应用 SoftReference
是为了避免缓存的数据量过大,呈现堆内存不够的状况。
三、总结来
当然,这样的实现是为了不引入新的组件,减少零碎的开发和保护老本。如果自身零碎有应用第三方缓存的需要,例如须要长久化,分布式,缓存非凡策略等,那么大胆的应用第三方缓存吧!
正文完