乐观锁
总是认为不会产生并发问题，每次去取数据的时候总认为不会有其他线程对数据进行修改，因此不会上锁，但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS操作实现。
例如：
有这样一个表：
每次更新时update在条件后再附加一个时间为条件：
update user_info set password=‘somelog‘ where username=‘somelog‘ and time=‘2018-07-11‘;
因为如果并发操作，同一刻查询的时间一样，但是先插入时将时间更改，那么后更新的操作就不能进行，因为time的值被前一个操作更改了。
这就是乐观锁的实现原理，更新时附加一个版本号。
悲观锁
总是假设最坏的情况，每次取数据时都认为其他线程会修改，所以都会加锁（读锁、写锁、行锁等），当其他线程想要访问数据时，都需要阻塞挂起。可以依靠数据库实现，如行锁、读锁和写锁等，都是在操作之前加锁，在Java中，synchronized的思想也是悲观锁。
注：要使用数据库的悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。
悲观锁分为两种：共享锁和排它锁
共享锁是其它事务可以读但是不能写
排他锁是只有自己得事务有权限对此数据进行读写
SQL写法
共享锁（S）：
SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE;
排他锁（X)：
SELECT * FROM table_name WHERE ... FOR UPDATE;
加锁必须先开启事务：begin;（开启事务）->加锁、操作->commit;（提交事务，归还锁）
加锁分为显式加锁与隐式加锁，上面的写法是显式加锁。mysql在执行insert、update会自动加锁，mysql对select却不会加锁。
例如：
不加锁
select * from data where username=‘somelog’;
加排它锁：
select * from data where username=‘somelog’ for update;
如果一个事务加了排它锁之后，另外一个事务不加锁的select也可以查询到数据
以上可以看出，锁不是针对事务的，排它锁只有一把，谁拿了谁就可以进行更新，但是没有拿到锁的事务只要在select不加上排它锁也可以查询到数据。
原文地址：https://www.cnblogs.com/somelog/p/9295266.html