不建议继承 countdownlatch，因其为 final 类无法被继承；正确方式是基于 aqs 自定义同步器，通过继承 abstractqueuedsynchronizer 并封装用户 api 实现扩展。
不建议继承 CountDownLatch 来扩展自定义同步器。
CountDownLatch 是 final 类，无法被继承
CountDownLatch 的类声明为：
public final class CountDownLatch
Java 中用 final 修饰的类禁止被继承。任何尝试 extends CountDownLatch 的代码在编译时就会报错：
error: cannot inherit from final CountDownLatch
正确扩展同步器的方式：基于 AQS 实现
Java 并发包中绝大多数同步器（如 ReentrantLock、Semaphore、CountDownLatch 自身）都基于 AbstractQueuedSynchronizer（AQS）构建。若需自定义同步逻辑，应：
- 继承
AbstractQueuedSynchronizer，重写其核心方法（如tryAcquire、tryRelease、tryAcquireShared等） - 封装一个面向用户的 API 类（类似
CountDownLatch的 public 构造/await/countDown 接口），内部委托给 AQS 子类实例 - 根据语义选择独占模式或共享模式（
CountDownLatch使用共享模式）
简单示例：实现带超时重置功能的倒计时器
假设想支持「倒计时结束自动重置」或「await 时可响应中断+超时」——这不是 CountDownLatch 原生支持的，但可通过组合 + AQS 实现：
- 不继承
CountDownLatch，而是新建类ResettableCountDownLatch - 内部持有一个
Sync类（继承AQS），用state表示剩余计数 -
await()调用sync.acquireSharedInterruptibly(1) -
countDown()调用sync.releaseShared(1) - 重置操作可直接用
setState(newCount)（需保证线程安全，通常配合compareAndSetState或加锁）
为什么组合优于继承（即使它能被继承）
即使某个同步器不是 final，也不推荐继承：
-
CountDownLatch没有预留 hook 方法或 protected 成员，继承后无法改变其同步语义 - 其内部状态（
state）被 private finalSync类封装，子类无法访问或修改关键逻辑 - 违反“组合优于继承”原则：同步行为应通过委托和 AQS 定制，而非破坏原有封装
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
