异常分类:
Exception分为运行时异常RuntimeException和非运行时异常
如果不对运行时异常进行处理，那么出现运行时异常之后，要么是线程中止，要么是主程序终止。
如果不想终止，则必须捕获所有的运行时异常，决不让这个处理线程退出。队列里面出现异常数据了，正常的处理应该是把异常数据舍弃，然后记录日志。不应该由于异常数据而影响下面对正常数据的处理。
非运行时异常是RuntimeException以外的异常，类型上都属于Exception类及其子类。如IOException、SQLException等以及用户自定义的Exception异常。对于这种异常，JAVA编译器强制要求我们必需对出现的这些异常进行catch并处理，否则程序就不能编译通过。所以，面对这种异常不管我们是否愿意，只能自己去写一大堆catch块去处理可能的异常。
事务管理方式
事务管理对于企业应用来说是至关重要的，即使出现异常情况，它也可以保证数据的一致性。
spring支持编程式事务管理和声明式事务管理两种方式。
编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。
声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。
声明式事务管理也有两种常用的方式，一种是基于tx和aop名字空间的xml配置文件，另一种就是基于@Transactional注解。显然基于注解的方式更简单易用，更清爽。
-----.
使用说明
在项目中，
@Transactional(rollbackFor=Exception.class)，如果类加了这个注解，那么这个类里面的方法抛出异常，就会回滚，数据库里面的数据也会回滚。在@Transactional注解中如果不配置rollbackFor属性,那么事物只会在遇到RuntimeException的时候才会回滚,加上rollbackFor=Exception.class,可以让事物在遇到非运行时异常时也回滚.@Transactional注解的应用场景
下面代码的三种方案都是正确的（第一种是在类级别的注解上，第二种是在方法级别的注解上，第三种是在捕获异常后在catch里写上）
事务场景中，抛出异常被catch后，如果需要回滚，一定要手动回滚事务。 Positive example 1： /** * @author hjm * @date 2019/07/09 */ @Service @Transactional(rollbackFor = Exception.class) public class UserServiceImpl implements UserService { @Override public void save(User user) { //some code //db operation } } Positive example 2： /** * @author hjm * @date 2019/07/09 */ @Service public class UserServiceImpl implements UserService { @Override @Transactional(rollbackFor = Exception.class) public void save(User user) { //some code //db operation } } Positive example 3： /** * @author hjm * @date 2019/07/09 */ @Service public class UserServiceImpl implements UserService { @Autowired private DataSourceTransactionManager transactionManager; @Override @Transactional public void save(User user) { DefaultTransactionDefinition def = new DefaultTransactionDefinition(); // explicitly setting the transaction name is something that can only be done programmatically def.setName("SomeTxName"); def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); TransactionStatus status = transactionManager.getTransaction(def); try { // execute your business logic here //db operation } catch (Exception ex) { transactionManager.rollback(status); throw ex; } } }（二）编程式事务
1.编程式事务设计原理
在编程式事务处理的过程中，利用DefaultTransactionDefinition对象来持有事务处理实现。同时，在创建事务的过程中得到一个TransactionStatus对象，然后通过直接调用transactionManager的commit()和rollback()方法来完成事务。编程式事务与声明式事务处理的实现是一致的。 Positive example 3： /** * @author hjm * @date 2019/07/09 */ @Service public class UserServiceImpl implements UserService { @Autowired private DataSourceTransactionManager transactionManager; @Override @Transactional public void save(User user) { DefaultTransactionDefinition def = new DefaultTransactionDefinition(); // explicitly setting the transaction name is something that can only be done programmatically def.setName("SomeTxName"); def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); TransactionStatus status = transactionManager.getTransaction(def); try { // execute your business logic here //db operation } catch (Exception ex) { transactionManager.rollback(status); throw ex; } } }解释上述原因：
Spring框架的事务处理代码默认地 只 在抛出运行时和unchecked exceptions时才标识事务回滚。 也就是说，当抛出个RuntimeException 或其子类的实例时，（Errors 也一样 - 默认地 - 标识事务回滚。）从事务方法中抛出的Checked exceptions将 不 被标识进行事务回滚。
1、让checked 异常例外也回滚：在整个方法前加上 @Transactional(rollbackFor=Exception.class)
2、让unchecked 异常例外不回滚： @Transactional(notRollbackFor=RunTimeException.class)
3、不需要事务管理的(只查询的)方法：@Transactional(propagation=Propagation.NOT_SUPPORTED)
注意： 如果异常被try｛…｝catch｛…｝了，事务就不回滚了，如果想让事务回滚必须再往外抛try｛…｝catch｛throw Exception｝。
最近遇到了事务不回滚的状况:
默认spring事务只在发生未被捕获的 runtimeexcetpion时才回滚。 spring aop异常捕获原理：被拦截的方法需显式抛出异常，并不能经任何处理，这样aop代理才能捕获到方法的异常，才能进行回滚，默认状况下aop只捕获runtimeexception的异常，但能够经过
配置来捕获特定的异常并回滚 换句话说在service的方法中不使用try catch 或者在catch中最后加上throw new
runtimeexcetpion（），这样程序异常时才能被aop捕获进而回滚 解决方案：
方案1.例如service层处理事务，那么service中的方法中不作异常捕获，或者在catch语句中最后增长throw new
RuntimeException()语句，以便让aop捕获异常再去回滚，而且在service上层（webservice客户端，view层action）要继续捕获这个异常并处理
方案2.在service层方法的catch语句中增长：TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();语句，手动回滚，这样上层就无需去处理异常（如今项目的作法）
结论
结论一：对于@Transactional能够保证RuntimeException错误的回滚，若是想保证非RuntimeException错误的回滚，须要加上rollbackFor= Exception.class 参数。
结论二：try catch只是对异常是否能够被@Transactional 感知 到有影响。若是错误抛到切面能够感知到的地步，那就能够起做用。
结论三：因为REQUIRED属性，“两个事务”实际上是一个事务，处理能力看报错时刻，是否添加了处理非RuntimeException的能力。
扩展
Spring事务框架默认只在抛出RuntimeException和unchecked exceptions时才将事务回滚（Errors默认 - 事务回滚），可是抛出的Checked exceptions时将不进行事务回滚。ide
若是咱们但愿改变这个默认状况，能够按场景作设置：
抛出checked
exceptions时也回滚事务：@Transactional(rollbackFor=Exception.class)
抛出unchecked
excepitons时不回滚事务：@Transactional(notRollbackFor=RunTimeException.class)
不须要事务管理：@Transactional(propagation=Propagation.NOT_SUPPORTED)
注意：若是异常被try｛｝catch｛｝了，事务就不回滚了，若是想让事务回滚必须再往外抛try｛｝catch｛throw
Exception｝
3、补充代理
Spring团队的建议是你在具体的类（或类的方法）上使用 @Transactional注解，而不要使用在类所要实现的任何接口上。你固然能够在接口上使用 @Transactional
注解，可是这将只能zxdfj设置了基于接口的代理时它才生效。由于注解是不能继承的，这就意味着若是你正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，并且对象也将不会被事务代理所包装（将被确认为严重的）。所以，请接受Spring团队的建议而且在具体的类上使用
@Transactional 注解。 @Transactional
注解标识的方法，处理过程尽可能的简单。尤为是带锁的事务方法，能不放在事务里面的最好不要放在事务里面。能够将常规的数据库查询操做放在事务前面进行，而事务内进行增、删、改、加锁查询等操做。
学习翻译地址
Name TransactionMustHaveRollbackRuleSeverity MajorMessage 事务场景中，抛出异常被catch后，若是须要回滚，必定要手动回滚事务。Examples Positive example 1： /** * @author caikang * @date 2017/04/07 */ @Service @Transactional(rollbackFor = Exception.class) public class UserServiceImpl implements UserService { @Override public void save(User user) { //some code //db operation } } Positive example 2： /** * @author caikang * @date 2017/04/07 */ @Service public class UserServiceImpl implements UserService { @Override @Transactional(rollbackFor = Exception.class) public void save(User user) { //some code //db operation } } Positive example 3： /** * @author caikang * @date 2017/04/07 */ @Service public class UserServiceImpl implements UserService { @Autowired private DataSourceTransactionManager transactionManager; @Override @Transactional public void save(User user) { DefaultTransactionDefinition def = new DefaultTransactionDefinition(); // explicitly setting the transaction name is something that can only be done programmatically def.setName("SomeTxName"); def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); TransactionStatus status = transactionManager.getTransaction(def); try { // execute your business logic here //db operation } catch (Exception ex) { transactionManager.rollback(status); throw ex; } } }