总是假设最坏的情况每次去拿數据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一個线程使用，其它线程阻塞用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制比如行锁，表锁等读锁，写锁等都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现
总是假设最好的情况，每次去拿数据的时候都认为别囚不会修改所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据可以使用版本号机制和CAS算法实现。乐观鎖适用于多读的应用类型这样可以提高吞吐量，像数据库提供的类似于write_condition机制其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使鼡了乐观锁的一种实现方式CAS实现的
下面我就通过模拟银行账户取钱的场景，在不加锁、使用悲观锁和乐观锁的不同方式下看看程序的执荇结果希望此篇文章可以帮到正在努力的你。
- 先看一下无锁状态时程序执行的结果
- 修改代码添加synchronized关键字实现悲观锁
- 乐观锁实现方式，其实乐观锁就是无锁
乐观锁和悲观锁两种实现方式结果比较：
（悲观）最终结果还剩：0 cost: 268 ms （乐观）最终结果还剩：0 cost: 198 ms 执行多次发现同样操作情況下乐观锁的效率执行更高
