高并发下如何合理使用锁

在并发环境下想要共享变量，一旦涉及修改操作，就需要用到锁了。 Java 中的锁有这么几种：synchronized、reentrant lock、还有reentrant lock 衍生出的其他锁比如ReadWriteReentrantLock

锁性能比较：

这几种锁在争用量级不同的情况下性能是不同的，就synchronized、ReentrantLock来分析比较的话，看到网上有好多博客都在说sychronized 在争用频次非常高的情况下性能会急剧下降，这种观点是存在时效性的，就当前1.8版本使用体验而言，sychronized在大量争用的情况性能其实还好并不会出现所谓的急剧下降，倒是在激烈争用时sychronized的性能要好一些，这个问题去官网确认了下，就现状而言官方是建议使用sychronized的，这次的体验也是sychronized更好。因为当前JVM是对于sychronized做出了优化了，借鉴ReentrantLock的CAS加锁方式，并且引入了偏向锁、轻量级锁等特性后，常规情况下两者比较相似，实践中得到的体验是sychronized性能更好一点，可能是JVM层面加锁之后，并且编译器同时做优化Sychronized 更适合在用户态把加锁问题解决避免陷入内核态的线程阻塞更有用吧。

锁粒度：

synchronized 所支持的锁粒度相较于ReentrantLock来说是处于劣势的，但是对于大多数场景来说synchronized足够用了。

锁特性：

synchronized 支持的一些偏向锁只能说是性能上的特性不能算是功能上的，但是加锁方便，不需要显示加锁释放锁，不容易产生死锁，代码编写简单（编写简单这事儿并不是很在意，目的是提升性能） ReentrantLock 特性就比较丰富了，支持公平锁、锁超时，更大程度上避免了死锁，但是ReentrantLock 能够控制的粒度更细，并且衍生出来的工具十分好用，比如说读写锁，但是也产生了需要手动释放锁这个问题。 其他锁相关的基础知识，可以看一下我博客Java Concurrent系列的文章，这里就不过多赘述了。 这里重点要说的是使用锁的一些方式：

1、锁选择

鉴于上面性能比较的结果，推荐使用sychronized

2、锁粒度

粒度要尽可能的控制到小，避免不必要的加锁。因为同步块越长，线程持有锁的时间就越长，其他线程等待的时间就越长，如果整个都是加锁的，那么整个程序就变成串行处理了。

3、避免加锁

一些能够牺牲空间来进行ThreadLocal处理的，就没必要使用锁了，加锁完全是为了并发下逻辑的正确，如果有更好的解决方式，请避免使用锁，但是如果像是一些非得使用锁的情况，也务必主要锁的粒度，像是直接给函数加锁，实在是不应该。

4、减少部分加锁

比如限流计数器，我们需要先判定是否大于0再决定是否进行减一操作，这是经典的竞态条件，按理说应该是加锁的，但是如果一共就200个线程争用，我们就可以合理的控制了，count 初始值为1000，假设每个线程只发起一次请求，我们要保证的是count不会减到0以下，我们前800次其实是没必要进行同步处理的，只需要用下原子类就可以了。之后后面100多次再产生同步就好了。

5、相关并发工具的选择

在高qps下使用Concurrent 包下的工具时，一定要先知道原理或者看看源码再使用，切不可盲目使用因为很多工具一些特性是没有用的但是为了这些特性增加了很多额外的加锁操作。然后也要知道如果有刚好符合你的需求，一定要用API 这样才能得到更好的性能及更大的正确性保证。