在了解悲观锁和乐观锁之前，我们先了解一下什么是锁，为什么要用到锁？
技术来源于生活，锁不仅在程序中存在，在现实中我们也随处可见，例如我们上下班打卡的指纹锁，保险柜上的密码锁，以及我们我们登录的用户名和密码也是一种锁，生活中用到锁可以保护我们人身安全（指纹锁）、财产安全（保险柜密码锁）、信息安全（用户名密码锁），让我们更放心的去使用和生活，因为有锁，我们不用去担心个人的财产和信息泄露。
而程序中的锁，则是用来保证我们数据安全的机制和手段，例如当我们有多个线程去访问修改共享变量的时候，我们可以给修改操作加锁（syncronized）。当多个用户修改表中同一数据时，我们可以给该行数据上锁（行锁）。因此，当程序中可能出现并发的情况时，我们就需要通过一定的手段来保证在并发情况下数据的准确性，通过这种手段保证了当前用户和其他用户一起操作时，所得到的结果和他单独操作时的结果是一样的
没有做好并发控制，就可能导致脏读、幻读和不可重复读等问题，如下图所示：
由于并发操作，如果没有加锁进行并发控制，数据库的最终的一条数据可能为3也有可能为5，导致数值不准确 二、悲观锁和乐观锁
首先我们需要清楚的一点就是无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。
2.1、悲观锁悲观锁（Pessimistic Lock）： 就是很悲观，每次去拿数据的时候都认为别人会修改。所以每次在拿数据的时候都会上锁。这样别人想拿数据就被挡住，直到悲观锁被释放，悲观锁中的共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程
但是在效率方面，处理加锁的机制会产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，如果已经锁定了一个线程A，其他线程就必须等待该线程A处理完才可以处理
数据库中的行锁，表锁，读锁（共享锁），写锁（排他锁），以及syncronized实现的锁均为悲观锁
悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证，
乐观锁（Optimistic Lock）： 就是很乐观，每次去拿数据的时候都认为别人不会修改。所以不会上锁，但是如果想要更新数据，则会在更新前检查在读取至更新这段时间别人有没有修改过这个数据。如果修改过，则重新读取，再次尝试更新，循环上述步骤直到更新成功（当然也允许更新失败的线程放弃操作）,乐观锁适用于多读的应用类型，这样可以提高吞吐量
相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本（version）或者是时间戳来实现，不过使用版本记录是最常用的。
乐观控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。 三、锁的实现
悲观锁阻塞事务、乐观锁回滚重试：它们各有优缺点，不要认为一种一定好于另一种。像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行重试，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
3.1 悲观锁的实现方式场景：
有用户A和用户B，在同一家店铺去购买同一个商品，但是商品的可购买数量只有一个
下面是这个店铺的商品表t_goods结构和表中的数据：
在不加锁的情况下，如果用户A和用户B同时下单，就会报错。
悲观锁的实现，往往依靠数据库提供的锁机制，在数据库中，我们如何用悲观锁去解决这个事情呢？
加入当用户A对下单购买商品（臭豆腐）的时候，先去尝试对该数据（臭豆腐）加上悲观锁
加锁失败：说明商品（臭豆腐）正在被其他事务进行修改，当前查询需要等待或者抛出异常，具体返回的方式需要由开发者根据具体情况去定义