数据库的乐观锁和悲观锁并非真实的锁

开局

我们平时编写程序的时候，有很多情况下需要考虑线程安全问题，一个全局的变量如果有可能会被多个同时执行的线程去修改，那么对于这个变量的修改就需要有一种机制去保证值的正确性和一致性，这种机制普遍的做法就是加锁。其实也很好理解，和现实中一样，多个人同时修改一个东西，必须有一种机制来把多个人进行排队。计算机的世界中也是如此，多个线程乃至多个进程同时修改一个变量，必须要对这些线程或者进程进行排队。数据库的世界亦是如此，多个请求同时修改同一条数据记录，数据库必须需要一种机制去把多个请求来顺序化，或者理解为同一条数据记录同一时间只能被一个请求修改。

锁是数据库中最为重要的机制之一，无论平时写的select语句，还是update语句其实在数据库层面都和锁息息相关。如果没有锁机制，操作数据的时候可能会发生以下情况：

1. 更新丢失：多个用户同时对一个数据资源进行更新，必定会产生被覆盖的数据，造成数据读写异常。
2. 不可重复读：如果一个用户在一个事务中多次读取一条数据，而另外一个用户则同时更新啦这条数据，造成第一个用户多次读取数据不一致。
3. 脏读：第一个事务读取第二个事务正在更新的数据表，如果第二个事务还没有更新完成，那么第一个事务读取的数据将是一半为更新过的，一半还没更新过的数据，这样的数据毫无意义。
4. 幻读：第一个事务读取一个结果集后，第二个事务，对这个结果集经行增删操作，然而第一个事务中再次对这个结果集进行查询时，数据发现丢失或新增。

数据管理角度

在数据库管理的角度或者数据行的角度来说，数据库锁可以分为共享锁和排它锁，这是面试过程