乐观锁和悲观锁
乐观锁
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。
乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的（同时读时不影响，写时判断，失败时重新判断）。
版本号机制:
一般是说在数据表中加上一个数据库版本号version字段，在表述数据被修改的次数当数据被修改时，它的version 值会加1。
如：
当然线程A需要更新数据值时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值为当前数据库中的 version 值相等时才更新，否则意外着此操作失败。
CAS(compare and swap) 比较并交换，有三个操作数，内存地址V ，预期值B，要替换得到的目标值A;
CAS指令执行时，比较内存地址V与预期值B是否相等，若相等则将A赋给B，(不相等则会循环比较直到相等)整个比较赋值操作是一个原子操作;
悲观锁
在多线程访问共享资源时，同时只允许一个线程独享此资源，其他线程都被悲观锁阻塞，只有当前拥有锁的线程释放锁，其他线程才能被唤起竞争这个资源，每个线程在获取资源前都要悲观的检查该资源是否已经被其他线程占用，所以悲观锁的开销是巨大的，但安全性高。
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
其他解释
乐观锁与悲观锁并不是特指某个锁，而是在并发情况下保证数据完整性的不同策略。
悲观锁指的就是我们平常使用的加锁机制，它假设我们总是处于最坏的情况下，如果不加锁数据完整性就会被破坏。
乐观锁指是一种基于冲突检测的方法，检测到冲突时操作就会失败。
synchronized在锁升级过程中，处于自旋锁时有CAS操作，为何还称synchronized是悲观锁？
其实这样想，在java代码层次，我们使用synchronized修饰方法时，多个线程访问共享资源时，站在方法角度，无论是读或者写，前提都是要获取对象的锁才能进行，这种就是悲观的体现。在这使用过程中，无关锁升级过程的。
至于在自旋锁时有CAS操作，我们不能站在cas的角度去理解，而是自旋锁最终的执行结果就是会锁住资源，让其他线程无法进行读写。
如果站在cas角度，那cas本身这个操作确实是一种乐观的体现。
使用场景
乐观锁适用于写比较少的情况下（多读场景），悲观锁适用于多写的情况下。