分别是原子性、一致性、隔离性、持久性。
目前成都创新互联公司已为上千余家的企业提供了网站建设、域名、虚拟空间、网站托管、企业网站设计、芮城网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。举例来说，假设用户A和用户B两者的钱加起来一共是1000，那么不管A和B之间如何转账、转几次账，事务结束后两个用户的钱相加起来应该还得是1000，这就是事务的一致性。
隔离性是当多个用户并发访问数据库时，比如同时操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务已经正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成。否则的话就会造成我们虽然看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。这是不允许的。
在数据库操作中，在并发的情况下可能出现如下问题：
正是为了解决以上情况，数据库提供了几种隔离级别。
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted(未授权读取、读未提交)、Read committed（授权读取、读提交）、Repeatable read（可重复读取）、Serializable（序列化），这四个级别可以逐个解决脏读、不可重复读、幻象读这几类问题。
虽然数据库的隔离级别可以解决大多数问题，但是灵活度较差，为此又提出了悲观锁和乐观锁的概念。
悲观锁，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制。也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统的数据访问层中实现了加锁机制，也无法保证外部系统不会修改数据。
商品t_items表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单（此时该商品无法再次下单），那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。
如果不采用锁，那么操作方法如下：
但是上面这种场景在高并发访问的情况下很可能会出现问题。例如当第一步操作中，查询出来的商品status为1。但是当我们执行第三步Update操作的时候，有可能出现其他人先一步对商品下单把t_items中的status修改为2了，但是我们并不知道数据已经被修改了，这样就可能造成同一个商品被下单2次，使得数据不一致。所以说这种方式是不安全的。
在上面的场景中，商品信息从查询出来到修改，中间有一个处理订单的过程，使用悲观锁的原理就是，当我们在查询出t_items信息后就把当前的数据锁定，直到我们修改完毕后再解锁。那么在这个过程中，因为t_items被锁定了，就不会出现有第三者来对其进行修改了。需要注意的是，要使用悲观锁，我们必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。我们可以使用命令设置MySQL为非autocommit模式： set autocommit=0;
设置完autocommit后，我们就可以执行我们的正常业务了。具体如下：
上面的begin/commit为事务的开始和结束，因为在前一步我们关闭了mysql的autocommit，所以需要手动控制事务的提交。
上面的第一步我们执行了一次查询操作： select status from t_items where id=1 for update; 与普通查询不一样的是，我们使用了 select…for update 的方式，这样就通过数据库实现了悲观锁。此时在t_items表中，id为1的那条数据就被我们锁定了，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。需要注意的是，在事务中，只有 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 操作同一个数据时才会等待其它事务结束后才执行，一般 SELECT ... 则不受此影响。拿上面的实例来说，当我执行 select status from t_items where id=1 for update; 后。我在另外的事务中如果再次执行 select status from t_items where id=1 for update; 则第二个事务会一直等待第一个事务的提交，此时第二个查询处于阻塞的状态，但是如果我是在第二个事务中执行 select status from t_items where id=1; 则能正常查询出数据，不会受第一个事务的影响。
使用 select…for update 会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认Row-Level Lock，所以只有「明确」地指定主键或者索引，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。举例如下：
1、 select * from t_items where id=1 for update;
这条语句明确指定主键（id=1），并且有此数据（id=1的数据存在），则采用row lock。只锁定当前这条数据。
2、 select * from t_items where id=3 for update;
这条语句明确指定主键，但是却查无此数据，此时不会产生lock（没有元数据，又去lock谁呢？）。
3、 select * from t_items where name='手机' for update;
这条语句没有指定数据的主键，那么此时产生table lock，即在当前事务提交前整张数据表的所有字段将无法被查询。
4、 select * from t_items where id0 for update; 或者 select * from t_items where id1 for update; （注：在SQL中表示不等于）
上述两条语句的主键都不明确，也会产生table lock。
5、 select * from t_items where status=1 for update; （假设为status字段添加了索引）
这条语句明确指定了索引，并且有此数据，则产生row lock。
6、 select * from t_items where status=3 for update; （假设为status字段添加了索引）
这条语句明确指定索引，但是根据索引查无此数据，也就不会产生lock。
乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以只会在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回用户错误的信息，让用户决定如何去做。实现乐观锁一般来说有以下2种方式：
修改方法
有两种方法可以对配置了 systemd 的程序进行资源隔离：1. 命令行修改：通过执行 systemctl set-property 命令实现，形式为 systemctl set-property name parameter=value；修改默认即时生效。2. 手工修改文件：直接编辑程序的 systemd unit file 文件，完成之后需手工执行 systemctl daemon-reload 更新配置，并重启服务 systemctl restart name.service。
systemd unit file 里支持的资源隔离配置项，如常见的：
CPUQuota=value
该参数表示服务可以获取的最大 CPU 时间，value 为百分数形式，高于 100% 表示可使用 1 核以上的 CPU。与 cgroup cpu 控制器 cpu.cfs_quota_us 配置项对应。
MemoryLimit=value
该参数表示服务可以使用的最大内存量，value 可以使用 K, M, G, T 等后缀表示值的大小。与 cgroup memory 控制器 memory.limit_in_bytes 配置项对应。
事务的4种隔离级别
READ UNCOMMITTED 未提交读，可以读取未提交的数据。READ COMMITTED 已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句， InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。 Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ 可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE 序列化
在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身间隙)，以及了解整个数据范围的全集组成。
数据范围全集组成
SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；
SQL 语句根据条件扫描到的可能需要加锁的数据范围；
以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）
先来总体说一下我对这个问题的理解，用一句话概括：
数据库是可以控制事务的传播和隔离级别的，Spring在之上又进一步进行了封装，可以在不同的项目、不同的操作中再次对事务的传播行为和隔离级别进行策略控制。
注意：Spring不仅可以控制事务传播行为（PROPAGATION_REQUIRED等），还可以控制事务隔离级别（ISOLATION_READ_UNCOMMITTED等）。
（以下是个人理解，如果有瑕疵请及时指正）
下面我具体解释一下：
为了大家能够更好的理解，先来明确几个知识点：
事务的传播行为：简单来说就是事务是手动提交还是自动提交，事务什么时候开始，什么时候提交。
事务的隔离级别：简单来说，就四个，提交读，提交读，重复读，序列化读。
首先我来描述一下，数据库（mysql）层面上对于事务传播行为和隔离级别的配置和实验方法：
数据库层面（采用命令行）：其实mySql命令行很简单，希望实验操作一下：
//连接数据库，我这里是本地，后面是用户名密码，不要打分号，如果指令不行，配置下环境变量，网上有很多。
1. cmd中执行：mysql -hlocalhost -uroot -pmysql
//查看本地数据库事务传播行为是手动提交（0），还是自动提交（1）。
2.select @@autocommit;
//如果是0，希望设置为手动提交,这里其实是设置本对话的autocommit，因为如果你再开一个cmd，发现还是没改回来，如果想修改全局的，网上有global方法。
3.set @@autocommit=0;
//然后查询本地数据库中的一条记录,我本地数据库为test1;
4.use test1;
5.select * from task where taskid=1;
//同时新开一个窗口cmd，连接数据库，并且修改这条记录，update语句我就不写了，或者直接修改数据库本条记录。
//再次执行select * from task where taskid=1;发现值没变。OK因为此时数据库隔离级别为repeatable read 重复读，因为mysql默认的隔离级别是重复读。
//修改数据库隔离级别
6.set global transaction isolation level read committed;
//查看一下，可能需要重新连接一下
7.select @@tx_isolation;
//这时在执行一下4,5操作，发现值变了，ok。因为已经改变了数据库隔离级别，发生了重复读出不同数据的现象。
（以上操作希望有不明白的上网自学一下，很有用，先把数据库隔离级别弄明白了）
然后再来讲一下，Spring对事务传播行为和隔离级别的二次封装。
因为不同项目可能在一个mysql的不同数据库上，所以可以在项目中配置数据库的传播行为和隔离级别：
关于spring的传播行为（PROPAGATION_REQUIRED、PROPAGATION_REQUIRED等），我《数据库隔离级别（mysql+Spring）与性能分析 》文章中有讲，网上也有很多相关资料，我就不说了。
关于spring的事务隔离级别与数据库的一样，也是那四个，多了一个default，我也不仔细讲了。
下面主要讲一下spring的配置方法：
property name="transactionAttributes"
props
prop key="save*"PROPAGATION_REQUIRED/prop
prop key="update*"PROPAGATION_REQUIRED/prop
prop key="delete*"PROPAGATION_REQUIRED/prop
prop key="get*"PROPAGATION_REQUIRED,readOnly/prop
prop key="find*"PROPAGATION_REQUIRED,ISOLATION_READ_UNCOMMITTED/prop
/props
就以find为例，可以配置这么配置，前面是控制传播行为，后面是控制事务隔离级别的。那么这时哪怕数据库层面上是重复读，但是还是以这里为准，你会发现在同一个事务中两次查询的结果是不一样的。
最后扫除一个盲区，readonly这个属性，是放在传播行为中的，一般书都这么归类，我也尝试了一下，readonly并不能影响数据库隔离级别，只是配置之后，不允许在事务中对数据库进行修改操作，仅此而已。
术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。
隔离级别的产生
在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。
所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。
事务的4种隔离级别
READ UNCOMMITTED 未提交读，可以读取未提交的数据。READ COMMITTED 已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句， InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。 Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ 可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE 序列化
在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身间隙)，以及了解整个数据范围的全集组成。
数据范围全集组成
SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；
SQL 语句根据条件扫描到的可能需要加锁的数据范围；
以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）
1. 数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）
整形，对值具有唯一约束条件的数据范围 1～5 ，
已有数据1、2、3、4、5，此时数据范围已被完全填充；
整形，对值具有唯一约束条件的数据范围 1 和 5 ，
已有数据1、5，此时数据范围已被完全填充；
2. 数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）
整形的数据范围 1～5 ，
已有数据 1、2、3、4、5，但是因为没有唯一约束，
所以数据范围可以继续被 1～5 的数据重复填充；
整形，具有唯一约束条件的数据范围 1～5 ，
已有数据 2，5，此时数据范围未被完全填充，还可以填充 1、3、4 ；
3. 数据范围内没有任何数据（存在间隙）
如下：
整形的数据范围 1～5 ，数据范围内当前没有任何数据。
在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。
无控制的并发所带来的问题
并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。
1. 范围内已有数据更改导致的：
更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，
由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；
脏读： 一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。
这时，另外一个事务也来读取同一条记录，如果不加控制，
第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。
这种现象就叫“脏读”。
2. 范围内数据量发生了变化导致：
不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，
却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。
这种现象就叫“不可重复读”。
幻读：一个事务按相同的查询条件重新读取以前检索过的数据，
却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。
可以简单的认为满足条件的数据量变化了。
因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。
MySQL 隔离级别的实现
InnoDB 通过加锁的策略来支持这些隔离级别。
行锁包含：
Record Locks
索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，
这种情况下，InnoDB 创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。
Gap Locks
间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。
间隙锁是性能和并发之间权衡的一部分。
对于无间隙的数据范围不需要间隙锁，因为没有间隙。
Next-Key Locks
索引记录上的记录锁和索引记录之前的 gap lock 的组合。
假设索引包含 10、11、13 和 20。
可能的next-key locks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：
(负无穷大, 10] (10, 11] (11, 13] (13, 20] (20, 正无穷大) 对于最后一个间隔，next-key将会锁定索引中最大值的上方，
左右滑动进行查看
"上确界"伪记录的值高于索引中任何实际值。
上确界不是一个真正的索引记录，因此，实际上，这个 next-key 只锁定最大索引值之后的间隙。
基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要 gap lock。
对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。
默认的 REPEATABLE READ 隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。
READ COMMITTED 已提交读，不匹配行的记录锁在 MySQL 评估了 where 条件后释放。
对于 update 语句，InnoDB 执行 "semi-consistent" 读取，这样它会将最新提交的版本返回到 MySQL，
以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。
总结延展：
唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。
当 where 条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。
行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。
例如，
在 session A 对符合条件的某聚簇索引加锁时，可能 session B 已持有该聚簇索引的 Record Locks，而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。
session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。
session A 通过索引 idA，session B通过索引 idB 。
当 where 条件获取的数据无间隙时，无论隔离级别为 rc 或 rr，都不会存在间隙锁。
比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。
间隙锁的目的在于阻止数据插入间隙，所以无论是通过 insert 或 update 变更导致的间隙内数据的存在，都会被阻止。
rc 隔离级别模式下，查询和索引扫描将禁用 gap locking，此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）。
rr 模式下，为了防止幻读，会加上 Gap Locks。
事务中，SQL 开始则加锁，事务结束才释放锁。
就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。
就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。
锁只是并发控制的一种粒度，只是一个很小的部分：
从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL 的 MTS 相同前置事务的多事务并发回放)
并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)
相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)
粒度加载的安全性能(如获取行锁前，先获取页锁，页锁在执行获取行锁操作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。
