spring事务和对象锁

对象锁（Lock/synchronized）的注意点：

1.对象锁可能锁住的范围比较大，导致接口性能下降，造成线程阻塞；

2.对象锁的唯一性问题，如果不是全局唯一锁（使用spring容器对象或static对象只能保证同一服务器唯一，不能保证全局唯一），将起不到锁的作用，最好使用分布式锁；

spring事务：

spring事务本质上使用数据库事务，而数据库事务本质上使用数据库锁，所以spring事务本质上使用数据库锁，开启spring事务意味着使用数据库锁；

spring事务实际使用AOP拦截注解方法，然后使用动态代理处理事务方法，捕获处理过程中的异常，spring事务其实是把异常交给spring处理；

spring事务只有捕获到异常才会终止或回滚，如果你在程序中try/catch后自己处理异常而没有throw，那么事务将不会终止或回滚，失去事务本来的作用；

spring事务会捕获所有的异常，但只会回滚数据库相关的操作，并且只有在声明了rollbackForClassName="Exception"之类的配置才会回滚；

spring事务会回滚同一事务中的所有数据库操作，本质上是回滚同一数据库连接上的数据库操作；

spring事务总结：

spring事务本质上使用数据库锁；

spring事务只有在方法执行过程中出现异常才会回滚，并且只回滚数据库相关的操作；

对象锁和spring事务的对比：

对象锁可以保证数据一致性和业务逻辑正确性，但不能保证并发性；

spring事务不能严格保证数据一致性和业务逻辑正确性，但具有较好的并发性，因为只锁数据库行数据；

建议：

如果只有insert操作，可以使用事务；

如果涉及update操作但不涉及其他业务逻辑，可以保守使用事务；

如果涉及update操作及其他业务逻辑，慎用事务，

并且数据库查询跟数据库更新之间尽量间隔较短，中间不宜插入太多其他逻辑，减少数据一致性的风险；

对数据一致性要求不高的情况下可以使用事务结合乐观锁，否则建议用锁；

spring事务为什么不能保证数据一致性和业务逻辑正确性：

1.如果事务方法抛异常，此时会回滚数据库操作，但已经执行的其他方法不会回滚，因此无法保证业务逻辑正确性；

2.即使事务方法不抛异常，也不能保证数据一致性（因为事务接口里的数据库操作在整个接口逻辑执行结束后才提交到数据库，在接口最后提交到数据库的前后很有可能带来数据一致性的问题），从而不能保证业务逻辑正确性；