@Transactional和synchronized同时使用时的一些问题以及解决

@Transactional和synchronized同时使用并不能保证事务一致性

背景

任何事情都有一个发生背景
有个需求【一个业务里面包含多个事务,而且还需要避免其他线程的影响,所幸的是该服务只需要启动单实例,不然还要考虑分布式的影响】
我的思路就是用@Transactional 和 synchronized来保证事务一致性和多线程影响,结果发现并没有如愿

分析原因

    @Transactional
    public ResultVo service(){
        synchronized (LOCK){
            //doservice
        }
    }

关于为什么不是用synchronized 关键字而是使用代码块锁是为了不影响其他方法,关键字默认锁的是当前类对象
一开始我的代码是这样的,乍一看好像没什么问题,但是为什么会出问题呢

排查问题

问题重现 : 一定要重现问题,任何重现不了的问题都不是问题,任何存在的问题都必能重现
由近到远 : 先确认自己的代码没问题,再考虑外部代码(如二方库,三方库)
从内到外 : 程序本质就是IPO,包含输入(input),程序(program)/指令集,输出(output),先确认输入没有问题,再确认代码逻辑
由浅入深 : 从易到难,从上到下,先上层API,http传输等,再底层API,源码,jvm等

说到这里,问题就比较容易分析了

首先我的输入没有问题

其次我逻辑代码也没有问题

接下来就是二方库和三方库了

由于事务用的是spring的事务,是基于aop实现的,ok找到问题了

由于spring的aop，会在@Transactional修饰的方法之前开启事务，之后再加锁，当锁住的代码执行完成后，在提交事务，
因此synchronized代码块执行是在事务之内执行的，可以推断在代码块执行完时，事务还未提交，其他线程进入synchronized代码块后，读取的库存数据不是最新的。

解决问题

在网上看到很多解决方案都在说在外层套一个方法,把锁的级别提高,或则说在controller加锁
这样可能会导致事务不会回滚
spring事务管理中，使用Synchronized修饰事务方法，同步为什么会失效
https://blog.csdn.net/weixin_54401017/article/details/129768305
这里提供一个解决方案,利用线程池,当 然业务代码还是要加@Transactional的!!!

private ExecutorService executorService = null;//线程池

public ResultVo updateOk(@RequestBody OtcTransferOutManageVo otcTransferOutManageVo){
        //如果线程池为null或则线程池被关闭了,创建一个单线程化线程池
        if (executorService == null || executorService.isShutdown()) {
            executorService = Executors.newSingleThreadExecutor();
        }
        if (otcTransferOutManageVo.getId() == null) {
            return ResultVoBuildUtils.buildResultVo( Constants.FAIL, "参数错误" );
        }
        //使用submit执行业务  Future和result.get()是为了保障线程同步,不然变成异步线程是无法捕获异常信息的
        Future<ResultVo> result = executorService.submit(()->{
            ResultVo resultVo = otcTransferOutManageService.updateOkStatus(otcTransferOutManageVo);
            LoggerHepler.writeInfoLog( TransferInController.class, resultVo.getMsg() );
            return resultVo;
        });
         executorService.shutdown();
        try {
            return result.get();
        } catch (Exception e) {
            LoggerHepler.writeErrorLog( TransferOutManageController.class, ServiceTypeENUM.ASSET_MANAGEMEN, BusinessTypeENUM.TRADE,
                   ExceptionCodeConstants.UPDATE_MYSQL_EXCEPTION, "updateOk error!", e );
            return ResultVoBuildUtils.buildFaildResultVo();
        }
    }

关于这段代码有几点需要说一下

newSingleThreadExecutor()创建单线程化的线程池

通过源码可以看到 :
该方法创建一个单一工作线程的线程池,如果此线程在执行过程中失败了,会有一个新的线程来继续完成未完成的工作
任务会被保证是顺序执行的(串行),并且再任意时间都不会超过一个活跃线程
这里基于的是LinkedBlockingQueue,这是一个线程安全的阻塞队列

shutdown()方法

在调用这个方法后,会在submit的任务执行完成后将线程池变为shutdown状态,拒绝新的任务(线程池不会立刻退出,直到任务完成)
如果已经关闭了,调用此方法也不会有额外的影响
此时不能再往线程池中添加新任务，否则会抛出RejectedExecutionException异常。

• Future && get()

因为这里需要获取线程执行的返回值,
无论是继承Thread类还是实现Runnable接口都无法获取到线程执行的返回值(默认是异步线程)
所以这里用到的是线程的第三种创建方式,实现callable接口重写call方法,当然重写call方法被我用lambda表达式隐含了
所以get()就是为了获取线程执行的返回值

submit()方法

传入一个Callable 任务,返回执行完成的返回值