请问下，Seata什么情况下会导致全局锁和本地锁会发生死锁？

seata事务多次操作同一数据可能导致回滚死锁的问题。

分支事务回滚时 会根据全局事务xid到branch_table中按照记录生成的时间(gmt_create) 正序查询所有分支事件记录放入List中，之后从List里倒序取出，挨个执行回滚！ 然后发现每次出现上述回滚异常 都是因为 有两条或多条branch_table记录的 gm_create是相同的 以致于后续回滚查询分支事务的时候 无法保证其先后顺序，而后执行回滚的顺序 就一样无法保证。

——参考链接。

1同一个分支事务,先后在不同资源上获取了互相竞争的锁资源顺序,造成死锁。
2分布式事务中有多个分支同时在不同资源上获取锁,但获取顺序不同或竞争锁资源同一个,也可能发生死锁。
3数据库层面如表锁粒度问题,可能造成行锁与表锁同时存在而导致锁竞争问题。

1. 事务并发冲突：当多个事务同时尝试获取全局锁和本地锁时，可能会出现并发冲突。如果这些事务在锁的获取顺序上存在问题，就可能导致死锁。
2. 事务提交顺序不一致：在 Seata 中，事务的提交顺序可能会影响锁的释放顺序。如果事务提交的顺序与锁的获取顺序不一致，可能导致死锁。
3. 异常处理不当：在处理异常时，如果未对锁进行正确的释放，可能会导致死锁。例如，在事务回滚时，如果未释放全局锁和本地锁，可能会导致死锁。
4. 系统故障：在系统故障恢复时，如果锁的状态未能正确恢复，可能会导致死锁。
   为了避免死锁，可以采取以下措施：
5. 确保事务的提交顺序与锁的获取顺序一致。
6. 在事务回滚时，确保释放全局锁和本地锁。
7. 使用 Seata 的 @GLOBALLOCK 注解，限制事务的并发访问。

Seata全局锁和本地锁发生死锁的情况可能包括以下几种情况：

并发冲突：当多个事务同时尝试访问同一资源时，可能会引发并发冲突，导致全局锁和本地锁发生死锁。
事务嵌套：如果一个事务嵌套了另一个事务，并且嵌套的事务需要等待外部事务释放资源，而外部事务又需要等待嵌套事务释放资源，这样就可能导致死锁。
锁顺序不一致：如果多个事务按照不同的顺序获取锁，可能会导致死锁。例如，事务A获取了资源1的锁，然后尝试获取资源2的锁，而事务B已经获取了资源2的锁，并尝试获取资源1的锁，这样就可能导致死锁。
事务超时：如果事务等待全局锁的时间过长，可能会导致死锁。因为长时间等待可能导致其他事务已经获取了所需的资源，而当前事务仍然在等待。
为了避免死锁，可以采取以下措施：

优化事务设计：尽量减少事务的嵌套和复杂度，避免出现循环依赖的情况。
保持锁顺序一致：在获取锁时，按照固定的顺序获取，避免出现混乱的锁顺序。
控制事务大小：尽量减少事务的执行时间，避免长时间等待导致死锁。
使用超时机制：设置合理的超时时间，当事务等待时间过长时，自动放弃锁的请求，避免死锁的发生。

Seata全局锁和本地锁发生死锁的情况通常是由于以下原因之一：

1.并发访问高并发资源：当多个事务同时访问同一资源，且该资源被Seata全局锁保护时，可能会出现死锁的情况。这是因为事务之间相互等待对方释放锁，导致无法继续执行。
2.事务逻辑复杂或执行时间长：如果事务逻辑复杂或执行时间较长，可能导致锁的持有时间增加，从而增加其他事务等待锁的时间，最终可能导致死锁。
3.网络延迟或不稳定：Seata全局锁的实现依赖于网络通信，如果网络延迟或不稳定，可能导致锁请求的响应不及时，进而引发死锁。
为了避免Seata全局锁和本地锁发生死锁，可以采取以下措施：

1.优化事务逻辑：尽量减少事务的复杂性和执行时间，以减少锁的持有时间。
2.调整锁的并发级别：根据业务需求和系统负载情况，适当调整Seata全局锁的并发级别，以平衡并发性能和死锁的风险。
3.优化网络环境：确保网络通信的稳定性和低延迟，以减少锁请求的响应时间。
4.监控和告警：通过监控系统监控Seata全局锁的使用情况，及时发现并处理潜在的问题，如死锁等。同时，设置告警机制，以便在出现问题时及时通知相关人员进行处理。

在Seata中，可能发生全局锁和本地锁死锁的情况包括以下几种：

• 事务1发起全局回滚时需要获取本地锁来进行回滚操作，但事务2此时已经持有了本地锁并试图获取全局锁。如果两者都无法获取到需要的锁，那么就会发生死锁。在这种场景下，Seata的解决方案是优先释放事务2的本地锁，从而让事务1的全局锁能去执行回滚操作。

• 另一个可能的场景涉及到两个全局事务tx1和tx2。他们分别对同一张表的同一字段进行更新操作。当tx1先开始并开启本地事务、拿到本地锁并完成初步更新后，就在本地事务提交前尝试获取该记录的全局锁。然而，如果tx2随后也开始并开启本地事务、拿到本地锁并进行进一步的更新操作，那么在tx1全局提交前，该记录的全局锁被tx1持有，导致tx2需要重试等待全局锁。

• 最后，如果tx1在二阶段全局回滚时需要重新获取该数据的本地锁以进行反向补偿的更新操作，而此时tx2仍在等待该数据的全局锁并且同时持有本地锁，那么tx1的分支回滚会失败。这种情况下，分支的回滚会一直重试，直到tx2的全局锁等锁超时并放弃全局锁以及回滚本地事务。

Seata提供了一个“全局锁重试”功能，1.5之前的版本中默认在结合@Transactional注解或手动开启本地事务下未开启该功能，可以通过下面这个配置来开启(面临回滚时可能全局锁和本地锁互相争抢导致死锁的可能)。建议直接升级1.5及以上版本,不要直接改动这个配置项.https://seata.io/zh-cn/docs/overview/faq/#36