java-乐观锁与悲观锁
我们今天就来了解一下锁中的乐观锁和悲观锁。
在面试中，如果是Java后天研发的工程师，很有可能会考到这一个知识点。所以今天也就来说下这个。
两者的概念
乐观锁
-
根据表面上来看每次去拿数据的时候认为别人都不会修改。所以不会上锁，有着更宽松的锁机制，减少了性能的开销。
-
在更新的时候会根据版本号进行判断是否有程序去修改这个数据，例如版本号等机制，使用版本号的机制在进行数据提交的时候，如果版本号大于对应的版本号那么进行更新，否则不进行更新。
-
在大多数情况下乐观锁使用在读多的应用上。在java中我们所了解的atomic包中，常用的线程安全的变量是使用的该锁机制。
-
乐观锁不能解决脏读问题
悲观锁
-
相对乐观锁来说，悲观锁具有强烈的独占和排他特性。该锁机制总是假设最坏的情况，每次去拿数据的时候都会认为别人会修改，所以在取数据的时候会进行加锁的操作。在这样的情况下，别的程序代码操作，需要进行等待操作，直到其拿到锁为止。
java中实现该两种机制的锁
在整个操作系统中，Cpu是分片操作的，在程序的执行过程中，会进行线程间的切换，也就是cpu的切换。Cpu的切换是很耗费时间，所以我们如果想减少CPU的切换，可以让某个线程一直持有该CPU，所以可以采用循环的方式来实现。
悲观锁
我们Java中使用的synchronized 就是一种典型的悲观锁的实现，该锁是拥有独占性，和排他性保证了线程 的安全，所以我们说synchronized是悲观锁。
-
优点：对数据处理安全起到了安全的作用。
-
缺点：
-
因为加锁 排他性，那么就会损耗性能，降低了并行性，增加了系统负载。
-
容易出现死锁的情况。
乐观锁
平常使用的CAS的安全操作类就属于乐观锁机制。还有我们经常说的自旋锁，轻量级锁，偏向锁这些也属于乐观锁。乐观锁为什么乐观，是因为减少了对CPU之间的切换，挂起，阻塞 ，唤醒等机制的操作造成的开销。所以在开销上，乐观锁更占一筹，减少了性能的损耗。建议对性能要求高，读请求多的使用该机制。
下面介绍下可以使用这些CAS操作一些类的使用
```
AtomicInteger one = new AtomicInteger();
AtomicLong atomicLong = new AtomicLong();
AtomicReference student = new AtomicReference<>();
one.get() ; //获得值
one.addAndGet(2) ; //增加指定的值
one.incrementAndGet(); //增加1
one.getAndSet(0); //先得到 原先值 然后在置为0
one.longValue(); //转为 long型
```转载：
