RichardX2023

@fengpan567 不是每次，不频繁。比如这次，由原先的实时导出改为做成一个导出中心，通过用户下载的方式实现。
改动就是把每次请求返回导出的 excel ，切换为导出推送到 oss ，并产生一个推送记录，用户通过推送记录获取 oss 的 url 来下载

@c3de3f21 是的，有 DevOps

@dayeye2006199 是个思路

@ZZ74 说明什么，我从头到尾写的多线程，本来就是多事务

@ZZ74 实际操作下应该就可以明白了，可能我的表述有问题，但是结果就是我说的那样，多个线程操作并且事务手动情况下，更新同一条数据就是会陷入无限的锁等待，可能我说死锁说法有问题

多线程操作适合用于查询、插入、删除，可能不适合更新。
更新操作数据库会自动上行锁，假如两个任务操作了同一行数据。

任务一拿到行锁-完成任务-等待任务二完成一起 commit 并释放锁，
任务二等待行锁占用者释放行锁，它得拿到锁才能进行更新。

所以任务一 一直等待事务提交释放行锁
任务二一直处于行锁等待状态。
这就是一个死锁状态。

@ZZ74
@ppto 多线程操作适合用于查询、插入、删除，可能不适合更新。
更新操作数据库会自动上行锁，假如两个任务操作了同一行数据。
任务一拿到行锁-完成任务-等待任务二完成一起 commit 并释放锁，
任务二等待行锁占用者释放行锁，它得拿到锁才能进行更新，
所以任务一一直等待事务提交释放行锁任务二一直处于行锁等待

@BQsummer https://developer.aliyun.com/article/1203834
这种方式的确是可行的，它实实在在的解决了事务的提交回滚在各个子线程处理的问题，但是，它也有自己的局限性，
```sqlSession.getMapper() ```问题就在这行代码，就是说只有通过这个方法获取的 Mapper 才能进行事务控制，通过 spring 周期管理的 Mapper 还是不受这个事务控制的，这个方法获取的 Mapper 是通过代理又创建了一个新的实例。

那么它的实现逻辑也就不能实现我的诉求，我希望是这个多线程工具对业务代码没有侵入性，也就是业务代码只要实现一个 Runnable 或者 Callable 就可以直接使用，这个显然需要对业务代码进行改动的

@monmon 老项目升级 jdk 比较困难