转载：https://www.cnblogs.com/fjdingsd/p/5273008.html
https://www.cnblogs.com/GreenLeaves/p/6567507.html
https://www.zhihu.com/question/30272728/answer/132403859
一. 数据库四大特性
本篇讲诉数据库中事务的四大特性（ACID），并且将会详细地说明事务的隔离级别。
如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下四个特性：
⑴ 原子性（Atomicity）
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，这和前面两篇博客介绍事务的功能是一样的概念，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
通过undo log来保证原子性，当事务回滚时能够撤销所有已经成功执行的sql语句。
⑵ 一致性（Consistency）
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
⑶ 隔离性（Isolation）
隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。
通过锁和MVCC来保证隔离性。
关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。
⑷ 持久性（Durability）
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。
通过redo log保证持久性。
从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性。也就是说ACID四大特性之中，C(一致性)是目的，A(原子性)、I(隔离性)、D(持久性)是手段，是为了保证一致性，数据库提供的手段。数据库必须要实现AID三大特性，才有可能实现一致性。例如，原子性无法保证，显然一致性也无法保证。
但是数据库层面能有保证，在代码里也需要做到响应的操作来保证一致性。
不考虑事务的隔离性会发生的问题
以上介绍完事务的四大特性(简称ACID)，现在重点来说明下事务的隔离性，当多个线程都开启事务操作数据库中的数据时，数据库系统要能进行隔离操作，以保证各个线程获取数据的准确性，在介绍数据库提供的各种隔离级别之前，我们先看看如果不考虑事务的隔离性，会发生的几种问题：
1 脏读
脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据。
当一个事务正在多次修改某个数据，而在这个事务中这多次的修改都还未提交，这时一个并发的事务来访问该数据，就会造成两个事务得到的数据不一致。例如：用户A向用户B转账100元，对应SQL命令如下
update account set money=money+100 where name=’B’; (此时A通知B)
update account set money=money - 100 where name=’A’;
当只执行第一条SQL时，A通知B查看账户，B发现确实钱已到账（此时即发生了脏读），而之后无论第二条SQL是否执行，只要该事务不提交，则所有操作都将回滚，那么当B以后再次查看账户时就会发现钱其实并没有转。
2 不可重复读
不可重复读是指在对于数据库中的某个数据，一个事务范围内多次查询却返回了不同的数据值，这是由于在查询间隔，被另一个事务修改并提交了。
例如事务T1在读取某一数据，而事务T2立马修改了这个数据并且提交事务给数据库，事务T1再次读取该数据就得到了不同的结果，发送了不可重复读。
不可重复读和脏读的区别是，脏读是某一事务读取了另一个事务未提交的脏数据，而不可重复读则是读取了前一事务提交的数据。
在某些情况下，不可重复读并不是问题，比如我们多次查询某个数据当然以最后查询得到的结果为主。但在另一些情况下就有可能发生问题，例如对于同一个数据A和B依次查询就可能不同，A和B就可能打起来了……
3 虚读(幻读)
幻读是事务非独立执行时发生的一种现象。例如事务T1对一个表中所有的行的某个数据项做了从“1”修改为“2”的操作，这时事务T2又对这个表中插入了一行数据项，而这个数据项的数值还是为“1”并且提交给数据库。而操作事务T1的用户如果再查看刚刚修改的数据，会发现还有一行没有修改，其实这行是从事务T2中添加的，就好像产生幻觉一样，这就是发生了幻读。
幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同）。所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）；不可重复读是指读到了已经提交的事务的更改数据(修改)，幻读是指读到了其他已经提交事务的新增或删除数据。
解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表。
事务的隔离级别
现在来看看MySQL数据库为我们提供的四种隔离级别：
Serializable (串行化)
可避免脏读、不可重复读、幻读的发生。
Repeatable read (可重复读)
可避免脏读、不可重复读的发生。
Read committed (读已提交)
可避免脏读的发生。
Read uncommitted (读未提交)
最低级别，任何情况都无法保证。
以上四种隔离级别最高的是Serializable级别，最低的是Read uncommitted级别，当然级别越高，执行效率就越低。像Serializable这样的级别，就是以锁表的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待，所以平时选用何种隔离级别应该根据实际情况。在MySQL数据库中默认的隔离级别为Repeatable read (可重复读)。
在MySQL数据库中，支持上面四种隔离级别，默认的为Repeatable read (可重复读)；而在Oracle数据库中，只支持Serializable (串行化)级别和Read committed (读已提交)这两种级别，其中默认的为Read committed级别。
在MySQL数据库中查看当前事务的隔离级别：
select @@tx_isolation;
在MySQL数据库中设置事务的隔离 级别：
set [glogal | session] transaction isolation level 隔离级别名称;
set tx_isolation=’隔离级别名称;’
例1：查看当前事务的隔离级别：
例2：将事务的隔离级别设置为Read uncommitted级别：
或：
记住：设置数据库的隔离级别一定要是在开启事务之前！
如果是使用JDBC对数据库的事务设置隔离级别的话，也应该是在调用Connection对象的setAutoCommit(false)方法之前。调用Connection对象的setTransactionIsolation(level)即可设置当前链接的隔离级别，至于参数level，可以使用Connection对象的字段：
在JDBC中设置隔离级别的部分代码：
后记：隔离级别的设置只对当前链接有效。对于使用MySQL命令窗口而言，一个窗口就相当于一个链接，当前窗口设置的隔离级别只对当前窗口中的事务有效；对于JDBC操作数据库来说，一个Connection对象相当于一个链接，而对于Connection对象设置的隔离级别只对该Connection对象有效，与其他链接Connection对象无关。
二. 原子性与一致性的理解
1、事务一致性
举个例子:假如你去银行转1000元给你的朋友,所有的操作都完成之后,并且提示你转账成功(假设银行是立即转账,不存在延时的情况),你发现你的账户上减少了1000元,但是你打电话给你的朋友确认时,而你的朋友的账户却没有因此增加1000元,那么我们认为这时候的数据就是不一致的状态!!!
在数据库的实现的应用场景中,一致性可以分为数据库外部的一致性和数据库内部的一致性：
i、外部的一致性:由外部的应用编码来实现,即银行的应用在进行转账的操作时,必须在同一事务内部调用对账户A和账户B的操作。如果在这个阶段出现错误,这不是数据库本身能解决的,也不属于我们要讨论的范围。
ii、数据库内部的一致性:在同一个事物内部的一组操作必须全部成功(或者全部失败)。这就是事物处理的原子性
2、事务原子性
上面说了事务的原子性是保证:事务内的一组操作全部成功(或者全部失败),为了实现原子性,就需要通过日志:将所有对数据的操作都写入日志,如果事务中的一部分操作已经成功,但后面部分操作,因为系统断电,操作系统崩溃等问题而没有成功执行,那么就要通过回溯日志,将前面已经成功执行的操作撤销,从而达到"全部执行失败"的效果。
3、体现事务原子性和数据库一致性和持久性的常见场景
数据库崩溃后重启,此时数据库处于不一致的状态,此时数据库必须做crash recovery操作,大致步骤如下:
a、通过日志REDO(重演所有执行成功但是未写入到磁盘的操作)
b、再对到数据库崩溃前没有执行完成的事务进行UNDO(撤销所有执行了一部分,但是有一部份还没有执行完成,且尚未提交的操作,保证事务的原子性)
c、crash recovery结束后,数据库恢复了一致性,可以继续工作
4、多线程下的事务存在的问题
在单线程下,事务的原子性,能保证数据库的一致性,但是在某些情况下,事务的原子性并不能保证数据库的一致性。具体场景如下:
问题:事务一将100元转到帐号A,那么他先读取帐号A,然后再在帐号A上加上100,但是在这个过程中间,事务二也修改了帐号A,给它加了100元,那么最后的结果应该是加了200元。但是当事务一最终完成后,帐号A只加了100,因为事务二的修改结果被事务一覆盖掉了。
为了保证数据的一致性,引入隔离性,既保证每一个事务看到的数据是一致的,确保一个事务在处理数据的同时,没有其他事务对自己正在处理的数据进行干扰,就好像其他事务都是不存在的一样,即事务在并发执行后的状态,和串行执行后的状态时一样的,实现隔离性主要通过加锁的方式。
下面是通过"锁"解决事务在多线程下的数据不一致性问题:
a、悲观锁
即事务将当前操作所有涉及到的对象加锁,操作完成后释放给其他对象使用,为了尽可能的提高性能,发明了各种粒度(数据库级/表级/行级)/各种性质(共享锁/排它锁/共享意向锁/共享排它锁/共享排他意向锁......)的锁。为了解决死锁问题,又发明了两阶段锁协议/死锁检测等一系列技术
b、乐观锁
即不同事务看到通一对象(一般是数据行)的不同历史版本,如果有两个事务同时修改了同一数据行,那么在较晚提交的事务提交使进行冲突检测。实现也有两种:一种是通过UNDO的方式获取数据行的历史版本,另一种是简单的在内存中保存数据行的不同历史版本,通过时间戳来区分
三. 事务的隔离级别细解
隔离性分为四个级别：
1读未提交：(Read Uncommitted)
2读已提交（Read Committed） 大多数数据库默认的隔离级别
3可重复读（Repeatable-Read) mysql数据库所默认的级别
4序列化（serializable）
四个级别的具体实现和不同的请下面细读：
首先程序是可以并发执行的，同样，在MySQL中，一个表可以由两个或多个进程同时来读写数据，这是没有问题的。
比如，此时有两个进程来读数据，这也没什么问题，允许。但是如果一个进程在读某一行的数据的过程中，另一个在进程又往这一行里面写数据（改、删），那结果会是如何？同样，如果两个进程都同时对某一行数据进行更改，以谁的更改为准？那结果又会怎样，不敢想象，是不是数据就被破坏掉了。所以此时是冲突的。
既然会冲突就要想办法解决，靠谁来解决，这时候就是靠锁机制来维护了。怎么使用锁来使他们不冲突？
在事务开始的时候可以给要准备写操作的这一行数据加一个排它锁，如果是读操作，就给该行数据一个读锁。这样之后，在修改该行数据的时候，不让其他进程对该行数据有任何操作。而读该行数据的时候，其他进程不能更改，但可以读。读或写完成时，释放锁，最后commit提交。这时候读写就分离开了，写和写也就分离开了。
注意：此时加锁和释放锁的过程由mysql数据库自身来维护，不需要我们人为干涉。mysql开发者给这个解决冲突的方案起了一个名字叫做：读未提交：(Read Uncommitted)。这也就是事务的第一个隔离性。
但是这个程度的隔离性仅仅是不够的。看下面的测试结果：
1）A修改事务级别为：未提交读。并开始事务，对user表做一次查询
2)B事务更新一条记录
3）此时B事务还未提交，A在事务内做一次查询，发现查询结果已经改变
4）B进行事务回滚
5）A再做一次查询，查询结果又变回去了
由试验得知：在一个进程的事务当中，我更改了其中的一行数据，但是我修改完之后就释放了锁，这时候另一个进程读取了该数据，此时先前的事务是还未提交的，直到我回滚了数据，另一个进程读的数据就变成了无用的或者是错误的数据。我们通常把这种数据叫做脏数据，这种情况读出来的数据叫做賍读。
怎么办？依然是靠锁机制。无非是锁的位置不同而已，之前是只要操作完该数据就立马释放掉锁，现在是把释放锁的位置调整到事务提交之后，此时在事务提交前，其他进程是无法对该行数据进行读取的，包括任何操作。那么数据库为此种状态的数据库操作规则又给了一个名字叫做：读已提交（Read Committed），或者也可以叫不可重复读。这也就是事务的第二个隔离性。
在某些情况下，不可重复读并不是问题，比如我们多次查询某个数据当然以最后查询得到的结果为主。但在另一些情况下就有可能发生问题，例如对于同一个数据A和B依次查询就可能不同，A和B就可能打起来了……
继续看下面的测试结果：
1）把隔离性调为READ-COMMITTED（读取提交内容）设置A的事务隔离级别，并进入事务做一次查询
2）B开始事务，并对记录进行修改
3）A再对user表进行查询，发现记录没有受到影响
4）B提交事务
5）A再对user表查询，发现记录被修改
试验进行到这里，你会发现，在同一个事务中如果两次读取相同的数据时，最后的结果却不一致。这里我们把这种现象称为：不可重复读。因为在第一个事务读取了数据之后，此时另一个事务把该数据给修改了，这时候事务提交，那么另一个事务在第二次读取的时候，结果就不一样，一个修改前的，一个是修改后的。
但是细心的你会发现，既然你说此种隔离性是在事务提交后才释放锁，那么在试验过程中，在该数据未提交前，另一个事务为什么也是仍然可以读取的呀。是我说错了吗？不是的，在这里mysql使用了一个并发版本控制机制，他们把它叫做MVCC，通俗的也就是说：mysql为了提高系统的并发量，在事务未提交前，虽然事务内操作的数据是锁定状态，但是另一个事务仍然可以读取，大多数数据库默认的就是这个级别的隔离性。但mysql不是。
而且不只是在更新数据时出现这个问题，在插入数据时仍然会造成类似的这样一种现象：mysql虽然锁住了正在操作的数据行，但它仍然不会阻止另一个事务往表插入新行新的数据。比如：一个事务读取或更新了表里的所有行，接者又有另一个事务往该表里插入一个新行，在事务提交后。原来读取或更改过数据的事务又第二次读取了相同的数据，这时候这个事务中两次读取的结果集行数就不一样。原来更新了所有行，而现在读出来发现竟然还有一行没有更新。这就是所谓的幻读。
为了防止同事务中两次读取数据不一致，（包括不可重读和幻读），接下来该如何继续做呢？！
mysql依然采取的是MVCC并发版本控制来解决这个问题。具体是：如果事务中存在多次读取同样的数据，MySQL第一次读的时候仍然会保持选择读最新提交事务的数据，当第一次之后，之后再读时，mysql会取第一次读取的数据作为结果。这样就保证了同一个事务多次读取数据时数据的一致性。这时候，mysql把这种解决方案叫做：可重复度（Repeatable-Read)，也就是上述所写的第三个隔离性，也是mysql默认的隔离级别。
注意：幻读和不可重复读（Read Committed）都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。
说到这里，真的就完事了吗？到这里其实mysql并未完全解决数据的一致性问题。只是在读取上做了手脚，解决了传统意义上的幻读和不可重复读。
例子：1 A事务开启，B事务开启。
2 B事务往表里面插入了一条数据，但还并未提交。
3 A事务开始查询了，并没有发现B事务这次插入的数据。然后此时B事务提交了数据。
4 于是乎，A事务就以为没有这条数据，就开始添加这条数据，但是却发现，发生了数据 重复冲突。
最后这个时候，该我们的最后一种隔离级别也是最高的隔离级：别序列化（serializable）登场了。
该隔离级别会自动在锁住你要操作的整个表的数据，如果另一个进程事务想要操作表里的任何数据就需要等待获得锁的进程操作完成释放锁。可避免脏读、不可重复读、幻读的发生。当然性能会下降很多，会导致很多的进程相互排队竞争锁。