2PL的一个流程图再次贴下
加锁阶段会一直加，解锁阶段就是一路解
下面说的是个人目前的理解，会有理解错误的部分，其实想找个地方学习讨论下
加锁阶段和解锁阶段如何处理下
demo主要的地方
swift
// 管理每个 key 对应的读写锁 锁冲突是全局的
private static final ConcurrentHashMap<String, ReadWriteLock> lockMap = new ConcurrentHashMap<>();
// 每个事务对应 key锁 可以提前检擦可能的锁冲突 long是个全局的事务ID
private static final ConcurrentHashMap<Long, List<ResourcLock>> transactionLocks = new ConcurrentHashMap<Long, List<ResourcLock>>();- 写了个demo大概的加锁阶段：有个方法支持一个事务添加锁，一直加一直添加
- 解锁阶段怎么处理：当前事务处理完毕后，（我这里打算根据事务ID得到对应所有锁直接全部释放掉，这样解锁就都释放掉了，那么加锁是一直加的，我不知道这个思路对不）
- demo这里还有个问题我暂且还没想到个好的处理办法，因为demo开放的函数是可以单个加锁和释放锁的能绕过事务管理的，这个权限改怎么处理？
- 上一篇我这里介绍了个碰到的问题ReadWriteLock在释放锁的时候有个限制（当前线程只能释放当前线程的锁，所以服务端处理的时候注意下线程）
回顾下JDBC的流程
- 1.注冊驱动 (仅仅做一次)
- 2.建立连接(Connection)
- 3.创建运行SQL的语句(Statement)
- 4.运行语句
- 5.处理运行结果(ResultSet)
- 6.释放资源
简单的解读下，个人理解我不确定对错
- 2.1建立连接这里是拿到了一个事务的ID（其实是一个全局的自增ID,下面的所有操作都在这个对应的事务内)
- 3.1这里就是一步一步加锁了
- 4.1运行语句处理数据了（这里就要判断是更新/删除/读取 处理数据加对应的锁）
- 5.1事务提交或者回滚了（这里提交或者回滚完毕的话就是锁应该也依次释放了）
- 6.1释放资源（我这里理解的大概的是数据库服务端的连接释放掉、类似tomat一个请求过来起一个线程访问结束这个线程也就结束了）
死锁问题
- 死锁出现：线程1 锁的资源A,B；-》线程2 锁的资源B,A;-》线程1 先锁定A；线程2先锁定B;-》这样1等待2的释放；2等待1的释放，谁也不主动释放只能等待手动介入了
- 死锁的问题，个人的简单理解如果按照上面的思路是可以避免的，因为所有的锁是全局的（读写锁）可以拿到，当锁冲突的时候那么我们能够检测到的就是先在全局去查一遍这个锁是否存在。检测后如果激进的处理就是整体回滚，中间的处理就是给锁一个获取超时的处理超时后就当作失败，或者就是一直阻塞的等待到上一个锁特殊处理释放掉。