返回信息流感谢大佬们的建议，改为pthread的rw_lock，read过程中命中缓存修改回收队列使用aes。
不过新的问题的是：原项目（github项目 libshmcache）使用的pthread_mutex在持有锁的进程意外退出后是可以解锁的，POSIX有相关的API，但是pthread_rw_lock没有这方面的东西，目前卡在这里。=.=
----------------------------------------------------------------------------------------------------------------
目前在实习，leader让我改写了一个key-value的本地缓存。存储的value在2～4M，淘汰使用了lru-1。
现在写的get()方法加的是互斥锁，IO耗时大约在200+ns，多进程访问单次get()耗时巨长，请问有什么好的解决思路？
我想到/知道的有：lock-free和异步IO，但只知道名词（for conversion）不知道该学什么怎么做 =.=
另外不知道能不能劝他别多进程访问，改成单进程的锁都省了。
这是一条镜像帖。来源：北邮人论坛 / cpp / #98909同步于 2019/4/27
该镜像源已超过 30 天没有更新，可能在源站已被删除。
CPP机器人发帖
【问题】本地缓存：IO耗时导致锁争用严重怎么解决？进程退出没
cauchyer
2019/4/27镜像同步16 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
IO耗时无论如何也是不可避免的了
听起来本地缓存是跑在同进程里的，不是外部的比如redis，多线程各自去get，也就用不上IO复用了
上面同学说的读写锁是一个好主意
更好一点的是，读/写key A与读/写key B应该也没什么关系，读写锁的粒度还可以更细一点
细到key粒度也没必要，细到线程粒度有足够概率防撞就好了，可以考虑用key的hash（或者key是int的话，直接位操作）分几个桶，每桶做读写锁
这样get的平均速度就只局限于不可避免的IO操作了
说的很好，不太理解的是，细化到key粒度没必要，而要分桶呢？有什么好处吗？
【 在 xxpxxxxp (xxpxxxxp) 的大作中提到: 】
: IO耗时无论如何也是不可避免的了
: 听起来本地缓存是跑在同进程里的，不是外部的比如redis，多线程各自去get，也就用不上IO复用了
: 上面同学说的读写锁是一个好主意
: ...................
另外，请教个问题，单进程内的锁有等待锁释放，抢夺锁的机制，分布式锁有实现这种机制的吗？还是如果获取失败，就只能放弃或者sleep重试吗？
【 在 xxpxxxxp (xxpxxxxp) 的大作中提到: 】
: IO耗时无论如何也是不可避免的了
: 听起来本地缓存是跑在同进程里的，不是外部的比如redis，多线程各自去get，也就用不上IO复用了
: 上面同学说的读写锁是一个好主意
: ...................
你成功把我迷惑了同学
key太多，不可能一个key一个锁，耗资源不说，怎么获取key对应的锁呢？听起来又要一个全局锁
分布式锁很多都可以wait的，基于zookeeper的，基于etcd的，都可以
不过你的多线程get要说的是分布式的，也就是说你的缓存是单进程的，请考虑直接用redis，再不济也考虑下redis单线程的实现
【 在 ray19950624 的大作中提到: 】
: 另外，请教个问题，单进程内的锁有等待锁释放，抢夺锁的机制，分布式锁有实现这种机制的吗？还是如果获取失败，就只能放弃或者sleep重试吗？
好的，谢谢。因为我看楼主说 多进程get IO耗时巨长，所以感觉是调用方多进程
【 在 xxpxxxxp (xxpxxxxp) 的大作中提到: 】
: 你成功把我迷惑了同学
: key太多，不可能一个key一个锁，耗资源不说，怎么获取key对应的锁呢？听起来又要一个全局锁
: 分布式锁很多都可以wait的，基于zookeeper的，基于etcd的，都可以
: ...................
哦我还以为你是楼主呢
我觉得缓存要是没有跟使用者一个进程的话，用Redis绝对比自己撸靠谱的多
【 在 ray19950624 的大作中提到: 】
: 好的，谢谢。因为我看楼主说 多进程get IO耗时巨长，所以感觉是调用方多进程