事务是指对系统进行的一组操作，为了保证系统的完整性，事务需要具有ACID特性，具体如下：

1. 原子性（Atomic）

     一个事务包含多个操作，这些操作要么全部执行，要么全都不执行。实现事务的原子性，要支持回滚操作，在某个操作失败后，回滚到事务执行之前的状态。

     回滚实际上是一个比较高层抽象的概念，大多数DB在实现事务时，是在事务操作的数据快照上进行的（比如，MVCC），并不修改实际的数据，如果有错并不会提交，所以很自然的支持回滚。

     而在其他支持简单事务的系统中，不会在快照上更新，而直接操作实际数据。可以先预演一边所有要执行的操作，如果失败则这些操作不会被执行，通过这种方式很简单的实现了原子性。

2. 一致性（Consistency）

     一致性是指事务使得系统从一个一致的状态转换到另一个一致状态。事务的一致性决定了一个系统设计和实现的复杂度。事务可以不同程度的一致性：

     强一致性：读操作可以立即读到提交的更新操作。

     弱一致性：提交的更新操作，不一定立即会被读操作读到，此种情况会存在一个不一致窗口，指的是读操作可以读到最新值的一段时间。

     最终一致性：是弱一致性的特例。事务更新一份数据，最终一致性保证在没有其他事务更新同样的值的话，最终所有的事务都会读到之前事务更新的最新值。如果没有错误发生，不一致窗口的大小依赖于：通信延迟，系统负载等。

     其他一致性变体还有：

     单调一致性：如果一个进程已经读到一个值，那么后续不会读到更早的值。

     会话一致性：保证客户端和服务器交互的会话过程中，读操作可以读到更新操作后的最新值。

3. 隔离性（Isolation）

     并发事务之间互相影响的程度，比如一个事务会不会读取到另一个未提交的事务修改的数据。在事务并发操作时，可能出现的问题有：

     脏读：事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据。

     不可重复读：在同一个事务中，对于同一份数据读取到的结果不一致。比如，事务B在事务A提交前读到的结果，和提交后读到的结果可能不同。不可重复读出现的原因就是事务并发修改记录，要避免这种情况，最简单的方法就是对要修改的记录加锁，这回导致锁竞争加剧，影响性能。另一种方法是通过MVCC可以在无锁的情况下，避免不可重复读。

     幻读：在同一个事务中，同一个查询多次返回的结果不一致。事务A新增了一条记录，事务B在事务A提交前后各执行了一次查询操作，发现后一次比前一次多了一条记录。幻读是由于并发事务增加记录导致的，这个不能像不可重复读通过记录加锁解决，因为对于新增的记录根本无法加锁。需要将事务串行化，才能避免幻读。

     事务的隔离级别从低到高有：

     Read Uncommitted：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。

     Read Committed：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。

     Repeated Read：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。

     Serialization：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。

     通常，在工程实践中，为了性能的考虑会对隔离性进行折中。

4. 持久性（Durability）

     事务提交后，对系统的影响是永久的。

在数据库中,所谓事务是指一组逻辑操作单元即一组sql语句。当这个单元中的一部分操作失败,整个事务回滚，只有全部正确才完成提交。
 
事务的ACID属性
 
1. 原子性（Atomicity）
原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，
要么都不发生。  
 
2. 一致性（Consistency）
事务必须使数据库从一个一致性状态变换到另外一个一致性状态。(数据不被破坏)
 
3. 隔离性（Isolation）
事务的隔离性是指一个事务的执行不能被其他事务干扰.
 
4. 持久性（Durability）
 
持久性是指一个事务一旦被提交，
它对数据库中数据的改变就是永久性的.
 
Hibernate是JDBC的轻量级封装，本身并不具备事务管理能力，在事务管理层，Hibernate将其委托给底层的JDBC或者JTA,以实现事务的管理和调度。
在JDBC中，
事务默认是自动提交的，
每次执行一个 SQL 语句时，如果执行成功，
就会向数据库自动提交，而不能回滚
 为了让多个 SQL 语句作为一个事务执行：
（1）执行语句前调用Connection
对象的setAutoCommit(false);

     以取消自动提交事务
（2）在所有的SQL
语句都成功执行后，调用commit();
方法提交事务
（3）在出现异常时，调用rollback();
方法回滚事务。

 

public class MyClass {

    private static volatile int count = 0;
    private static AtomicInteger atomicCount = new AtomicInteger(0);
    private static int synchronizedCount = 0;

    public static void main(String[] args) {
        //  分别调用，打印结果
        // volatileCount();
        //  atomicCount();
        synchronizedCount();
    }

    private static void volatileCount() {
        for (int i = 0; i < 10; i++) {
            Executors.newFixedThreadPool(3).execute(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(100);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    // 虽然使用volatile关键字修饰int变量，但是对于多线程的环境下，也很难保证没问题，所以一般用来修饰标志位
                    System.out.println("volatile count: " + ++count);
                }
            });
        }
    }
    //    打印结果：有重复数据，且顺序错乱。表示数据操作不是原子的，线程之间也不是有序的
    //    volatile count: 1
    //    volatile count: 5
    //    volatile count: 4
    //    volatile count: 3
    //    volatile count: 1
    //    volatile count: 2
    //    volatile count: 6
    //    volatile count: 7
    //    volatile count: 8
    //    volatile count: 9


    private static void atomicCount() {
        for (int i = 0; i < 10; i++) {
            Executors.newFixedThreadPool(3).execute(new Runnable() {
                @Override
                public void run() {
                    try {
                        Thread.sleep(100);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    // 通过使用Atomic包中的原子类保证数据操作是原子的（数据没有重复，表示是原子操作），但是不能保障有序性
                    System.out.println("atomic count: " + atomicCount.incrementAndGet());
                }
            });
        }
    }
    //    打印结果：虽然顺序错乱，但是数据没有重复，也就说明保障了数据的操作是原子的，但是线程间不是有序的
    //    atomic count: 1
    //    atomic count: 2
    //    atomic count: 3
    //    atomic count: 5
    //    atomic count: 8
    //    atomic count: 9
    //    atomic count: 10
    //    atomic count: 4
    //    atomic count: 7
    //    atomic count: 6


    private static void synchronizedCount() {
        for (int i = 0; i < 10; i++) {
            Executors.newFixedThreadPool(3).execute(new Runnable() {
                @Override
                public void run() {
                    synchronized (MyClass.class) {  // 通过synchronized关键字来保证线程之间的有序性
                        System.out.println("synchronized count: " + ++synchronizedCount);
                    }
                }
            });
        }
    }
    //    打印结果：没有重复数据，也没有错乱现象，说明数据操作是原子的，同时线程操作也是顺序的。同时也说明，有序性可以保障数据操作的原子性
    //    synchronized count: 1
    //    synchronized count: 2
    //    synchronized count: 3
    //    synchronized count: 4
    //    synchronized count: 5
    //    synchronized count: 6
    //    synchronized count: 7
    //    synchronized count: 8
    //    synchronized count: 9
    //    synchronized count: 10
}

事务指的就是一组原子性的sql查询
ACID

A：整个事务的全部操作要么全部完成要么全部不完成，不能只执行其中的一部分。



C：数据库总是从一个一致性的状态转换到另一个一致性状态consistency

转账之前和转账之后总余额没有变化

I：一个事务对数据库中所作的修改在提交之前对其他事务是不可见的,有四种隔离级别，innodb默认是可重复读Repetable read

show variables like ‘%iso%’ 查看事务的隔离级别或者是select @@tx_isolation

查看global的隔离级别为select @@global.tx_isolation

set  session tx_isolation=‘read-committed’;

未提交读：read uncommited,一个事务对数据进行了修改，即使事务还没有提交，对于其他事务也都是可见的，其他事务可以读取未提交的数据，就是脏读未提交的数据就是脏数据

已提交读:read commited，一个事务开始的时候只能看到已经的提交的事务做出的修改**(避免了脏读，但是不能避免幻读和 可重复读(两次执行同样的操作，可能会产生不同的结果))，也就是说一个事务从开始到提交之前做出的修改对其他事物是不可见的(不能避免更新操作带来的问题)**

可重复读：Repetable read，同一个事务多次读取同样的记录是相同的，可重复读不能避免幻读(不能避免删除和插入带来的问题)

可串行化:serializable,在读取的每一行数据上都加锁，可能会导致锁并发锁争用问题性能损耗大，除非在需要数据一致性的是时候并且接收没有并发的情况下，才考虑使用这种方式

幻读：幻读指的是一个事务在前后两次查询同一个范围的时候，后一次查询看到了前一次没有看到

幻读指的是

innodb：默认是可重复读，未提交读，已提交读，可重复读，可串行化这隔离级别逐渐增高**

D：一旦事务被提交，其所作的修改将会永久的保存在数据库中

什么是大事务？
大事务:运行时间比较长，操作的数据比较多的事务

比如:比如余额宝每天都要对所有的用户进行统计，展示等等

大事务的风险：

1.锁定的数据比较多，虽然innodb是行级锁，但是数据库基本上会将存在关联关系的数据一起锁定，造成大量的阻塞和锁超时

2.回滚的时间比较长

3.主库上执行完成之后将事务写道binlog中，要很长时间的话，会造成主从延时

如果处理大事务：

1.避免一次处理很多数据，分批

2.移除在事务中不必要的select操作。