juc之ConcurrentHashMap在我工作中的实践
Map是我工作中应用比较多的数据结构之一，主要用来存储一些kv的映射信息，如果是单线程环境下我会优先使用HashMap，但是如果在多线程环境下继续使用HashMap我不确定会不会被我老大打死，为了生命安全考虑我选用了大名鼎鼎的ConcurrentHashMap。
使用背景
笔者负责过一个http推送系统，其职责是定时将生产者者插入到库中的推送任务捞出来根据推送地址进行http推送，推送时需要进行RSA签名，但是加签用的私钥是每个接收者不同的，所以意味着每次在推送时我是需要根据推送者标识（统一叫appId）去获取私钥信息的，很显然每次查库不是个好办法，这时就需要加一层缓存来解决这个问题了。
为什么使用ConcurrentHashMap
最开始我是想用Redis这种集中缓存的，操作简单，而且不用考虑多节点之间数据的一致性，后来跟负责开放平台的同学沟通了一下（接收者是ISV，公私钥信息目前是开放平台同学线下派发的），公私钥信息被改动的频率很小，线上跑了两年多目前还没有ISV提出要更换，基于这一点我决定使用本地缓存，本地缓存的优点是减少了网络IO，性能更好，缺点是多节点之间数据一致性是个问题，如果数据不一致ISV验签失败会返回错误，但推送系统有个设计是如果推送失败了会阶梯式重试，整个重试过程持续12个小时，我只要把本地缓存的过期时间调小就好，最终会拿到正确的私钥信息（后来也想过设计明确的错误码，比如ISV返回SIGN_ERROR时主动刷新本地缓存，但是这涉及到接口协议的变更，最终还是搁置了），我为什么没有选择Ehcache，Guava这种成熟的缓存框架呢？一个原因是不太熟悉，第二个原因是我这个场景比较简单，不想引入一套框架进来。
步骤分解
1.根据appId去本地缓存中查询是否存在；
2.如果存在，判断是否过期，如果不过期直接返回，否则继续执行以下逻辑；
3.删除appId对应的Value
4.查询db；
5.将查询结果放到本地缓存中；
识别问题
上面的五步是一般使用缓存的大体流程，这五步涉及到的一些细节如下：
1.过期数据如何识别
2.过期数据如何删除
3.缓存并发更新如何处理
解决问题
1.如何识别过期数据：往本地缓存塞值的时候同时将过期时间塞进去，这块是将Value做了一层包装，大体结构如下：
public class CacheFutureTask<V> extends FutureTask<V>{
private long expireTime = -1;
private long createTime = -1;
private V result;
public CacheFutureTask (Callable<V> call){
super(call);
this.createTime = System.currentTimeMillis();
this.expireTime = this.createTime+ TimeUnit.MINUTES.toMillis(30);//三十分钟过期
}
//是否过期
public boolean isExpired(){
return System.currentTimeMillis() > this.expireTime ;
}
public CacheFutureTask(Runnable runnable, V result) {
super(runnable, result);
}
@Override
public V get() throws InterruptedException, ExecutionException {
return super.get();
}
}
2.如何删除过期数据：一般的缓存框架都支持主动删除和惰性删除，主动删除主要是为了尽快释放内存，实现起来有一定复杂度，我这个场景中数据量不大，目前几十条，短期内也不会有大幅增长，所以内存并不会成为瓶颈，基于此我只是实现了惰性删除，获取之后判断下是否过期，如果过期就删除，代码如下；
CacheFutureTask<OpenIsvAppDO> cacheFutureTask = null;
cacheFutureTask = isvAppInfos.get(appId);
if(cacheFutureTask != null && cacheFutureTask.isExpired()){
logger.info("appId:{} configInfo is expired,will load from db",appId);
isvAppInfos.remove(appId);
cacheFutureTask = null;
}
3.如何避免缓存并发更新：缓存存在的意义就是减少db的访问，但是在并发环境下每个线程都有机会去更新缓存，如果不做控制在高并发环境下对db是一种摧残，所以必须要控制并发更新缓存，更新时需要加锁，更新完成释放锁，不过要注意设置合理的超时时间，否则可能会有大量线程等待，严重的时候可能会撑爆jvm内存，这块用到了ConcurrentHashMap的putIfAbsent(K key, V value) 方法来实现单线程更新缓存，使用CacheFutureTask的get(long timeout, TimeUnit unit)方法来做到超时结束等待，代码如下：
CacheFutureTask<OpenIsvAppDO> cacheFutureTask = null;
try {
//缓存惰性删除逻辑
cacheFutureTask = isvAppInfos.get(appId);
if(cacheFutureTask != null && cacheFutureTask.isExpired()){
logger.info("appId:{} configInfo is expire,will load from db",appId);
isvAppInfos.remove(appId);
cacheFutureTask = null;
}
//如果本地缓存中不存在appId对应条目，就构造一个CacheFutureTask尝试插入
if(cacheFutureTask == null) {
Callable<OpenIsvAppDO> call = new Callable<OpenIsvAppDO>() {
@Override
public OpenIsvAppDO call() throws Exception {
return openIsvAppDAO.selectByAppIdAndStatus(appId, APP_STAUTS_ACTIVE);
}
};
CacheFutureTask<OpenIsvAppDO> futureTask = new CacheFutureTask<OpenIsvAppDO>(call);
//尝试插入appId对应缓存条目
cacheFutureTask = isvAppInfos.putIfAbsent(appId,futureTask);
//如果返回为null，说明当前线程拿到了锁，可以执行查询db逻辑
if(cacheFutureTask == null) {
cacheFutureTask = futureTask;
//执行run逻辑，run最终会将操作委派到Callable的call方法
futureTask.run();
}
}
//带着超时参数获取Value信息
return cacheFutureTask.get(10, TimeUnit.SECONDS);
}catch(Exception e) {
//如果发生异常，将appId对应的FutureTask从缓存中删除
isvAppInfos.remove(appId);
}
结语
以上就是我用ConcurrentHashMap来实现本地缓存的一个例子，之所以没有用一些成熟的框架是因为我遇到的这个场景比较简单，所以选择自己动手实现，还是那句话，适合的才是最好的，做技术选型的时候要结合实际情况。
