1：java中自带的锁有系统所sychronized与应用层面的锁lock，基于lock就介绍ReentrantLock。
基于这个层面的lock核心就是AQS，lock的底层原理实现还是依赖CAS，在jdk早期版本中，lock的性能是要优于sychronized的。主要是因为之前的版本sychronized一直是一把重量级锁需要去调用的操作系统。
2：而优化后的sychronized，在偏向锁与轻量级锁的实现依赖于对象体于CAS。关于他的具体介绍这个大家可以去百度他的实现原理。
在我们普通项目中要去保证一些数据操作的原子性，我们很多时候直接去使用java锁。但是很多场景直接的对方法枷锁不是特么高效的意见事情，例如多个人对不同的类型的数据进行操作，操作不同类型之间完全不必要有锁。如果系统的并发量不大，这样也是没什么问题的，当然也可以去使用分段锁。但是如果类型特别多，而且类型还是动态的，简单的使用分段锁的实现方式，也不是特别好了。
我想介绍一下我目前基于秒杀场景与防止超卖的实现，我使用的redis，我想要要说下我为什么使用redis来实现。很重要一点是因为redis的线程模型，大家应该都知道他是一个单线程的模型，他有点类似netty使用的reactor模型，无论在什么情况下，他都会只有一个命令的执行。其实大家也有一个疑惑点，这个的话跟使用队列有什么区别呢，其实在redis的模型中也是有一个队列的。所以的请求执行命令都在队列中，在大规模的场景中，我们可以有很多的redis，这意味着我们能有很多个类型的数据在并行执行。这样的操作我们对我们的业务层面代码影响是比较小的，如果是在微服务集群的应用部署情况下，我们还要去使用分布式锁，这样我们直接利用redis来操作，就节省了这些步骤，但是这样也是有缺点的，如果并发比较高，公司的redis做了一主多从，那么这样的设计也是有问题的。因为请求打在了计算之后的redis上，但是他多从，这样同一个类型的数据不在同一个redis中执行。当然这个可以是在业务中去控制的，我目前是在对redis封装的过程中基于不同的类型去做控制的。
3：对redis去实现这样我们存放数据到redis然后之间进去操作就可以了，业务相对简单。不需要去关心队列呀，锁呀这套东西。单体项目来说，直接使用是相对简单的。
