要真正杜绝锁误释放导致的数据错乱，关键是以泛型接口固化“谁加锁、谁续期、谁解锁”责任链：通过TClient、TResource、TRenewal三参数强约束加锁、续期、解锁全流程，强制身份绑定、持有权校验与标识匹配，并禁用弱类型API。
要真正杜绝因锁误释放导致的数据错乱，关键不是堆砌功能，而是用泛型接口把“谁加的锁、谁续的期、谁放的锁”这一整条责任链固化下来。核心在于：加锁时绑定唯一上下文，续期时校验持有权，释放时强制匹配标识——三者必须由同一泛型契约约束，不能靠约定，也不能靠文档。
泛型接口定义：明确锁生命周期的责任主体
定义一个带类型参数的锁接口，将客户端身份、锁资源标识、续期策略全部纳入泛型约束：
- TClient：代表锁持有者（如 ThreadId、RequestID、ServiceInstanceId），确保每个实例有不可伪造的身份
- TResource：代表被保护资源（如 "stock:1001"、"order:20260523"），避免 key 泛化导致误操作
- TRenewal：描述续期逻辑（如 FixedTtlRenewal、BackoffRenewal），禁止裸调 EXPIRE
接口方法签名强制携带泛型上下文，例如：
boolean tryLock(TClient client, TResource resource, Duration waitTime, Duration leaseTime)
void renew(TClient client, TResource resource) throws IllegalOwnerException
void unlock(TClient client, TResource resource) throws IllegalOwnerException
自动续期必须绑定持有者身份，且由守护线程内聚执行
续期不是“定期重设过期时间”，而是“以当前持有者身份发起一次原子续约请求”。若泛型未约束 client 类型，就可能出现 A 线程创建锁、B 线程启动续期线程、最终 B 续了 A 的锁这种反模式。
- 续期线程启动时，必须持有 TClient 实例的不可变快照（如 UUID 或加密 token），不能只传 ThreadLocal 引用
- 每次续期前，先用 Lua 脚本比对 Redis 中 value 是否仍等于该 client 快照值；不等则立即中止并记录告警
- 续期间隔固定为 leaseTime / 3，但首次续期延迟需随机偏移 100–500ms，防多实例续期风暴
释放锁必须通过泛型校验 + Lua 原子脚本双重保障
泛型接口的 unlock 方法不能接受任意字符串 key 和 value，而必须传入当初加锁时的 TClient 和 TResource 实例。内部实现直接调用预编译 Lua 脚本：
- Lua 脚本只做两件事：读取 key 对应 value → 判断是否等于传入的 client 标识 → 相等才 DEL，否则返回失败码
- Java 层收到非成功响应，抛出 IllegalOwnerException，业务代码无法忽略该异常，必须处理（如重试或熔断）
- 禁止提供“无参 unlock()”或“仅传 key 的 unlock(String key)”这类弱类型方法，从 API 层杜绝误用可能
实战中规避三个典型泛型滥用陷阱
即使用了泛型，也常因设计疏漏让安全机制失效：
- 泛型擦除后运行时丢失类型信息：避免在泛型方法里做 instanceof 判断，所有校验必须基于 client 实例的字段值（如 client.getId()），而非 class 类型
- client 实例可变导致身份漂移：TClient 必须是不可变类（@Immutable），禁止暴露 setter 或内部状态修改方法
- resource 标识未标准化引发 key 冲突：TResource 接口强制实现 toKey() 方法，统一生成规范 key（如 "lock:stock:" + skuId），不拼接原始字符串
