场景：

            小明账户中有10000元，小强账户中有10000元，小红账户中有0元

            有三个操作同时进行：小明给小红转账10元 ，小强给小红转账10元，小红自己往账户存入1元

            为了模拟高并发，我这里将上述操作复制300份，每份300个线程中同时执行

测试一：

代码如下：（测试代码，细节的判断我就省略了）

这里仅仅引入了事务机制，事务的隔离级别为 REPEATABLE_READ

测试内容     测试         同时开启900个线程             其中300个线程： 小明向小红转账10元             其中300个线程：小强向小红转账10元             其中300个线程：小红自己存入1元

    数据库初始值：

  期望值：

测试开始，转账中.......

3次测试的结果为：

分析：很明显这里是由于多线程操作同一数据遇到的线程同步安全问题，怎么解决呢？第一时间我想到的是加个同步锁：synchronization,加锁后进行第二次测试

测试二：

代码如下： 在测试一的基础上，加了同步锁synchronized 

测试内容     测试         同时开启900个线程             其中300个线程： 小明向小红转账10元             其中300个线程：小强向小红转账10元             其中300个线程：小红自己存入1元

    数据库初始值：

  期望值：

测试开始，转账中.......

测试结果：

分析：用时增加到17秒，结果还是会出错，这时为啥呢？ 由于上面的同步锁只锁了自己的方法，但是其他方法还是可以操作数据库的，有没有一种方法是给数据库的某条数据上锁呢，有的，这里可以使用悲观锁：顾名思义，就是很悲观的锁，事务在查询数据时，总是悲观的认为其它事务会操作这条数据，所以上了锁。直到事务commit才会释放。期间会阻塞其他事务想要给这条数据上锁。下面进行悲观锁测试。

测试3：

这里去掉了synchronization修饰符，使用悲观锁

在查询语句中添加悲观锁：

这里将数据量增加50倍测试：

测试内容     测试

循环50次执行以下操作：         同时开启900个线程             其中300个线程： 小明向小红转账10元             其中300个线程：小强向小红转账10元             其中300个线程：小红自己存入1元

    数据库初始值：

  期望值：

测试开始，转账中.......

测试结果：

用时13分钟

测试成功

总结：