关于 Semaphore 补充内容的错误

[HoeYeungHo]

#645 的补充内容中提到

Semaphore 与 CountDownLatch 一样，也是共享锁的一种实现。它默认构造 AQS 的 state 为 permits。当执行任务的线程数量超出 permits，那么多余的线程将会被放入等待队列 Park，并自旋判断 state 是否大于 0。只有当 state 大于 0 的时候，阻塞的线程才能继续执行,此时先前执行任务的线程继续执行 release() 方法，release() 方法使得 state 的变量会加 1，那么自旋的线程便会判断成功

有不准确的地方。多余的线程将会被放入等待队列 Park 后，不会再自旋判断 state 是否大于 0，而是等其他线程调用 release() 后，通过 AQS 的 doReleaseShared() 方法唤醒。

[Snailclimb]

#645 的补充内容中提到

Semaphore 与 CountDownLatch 一样，也是共享锁的一种实现。它默认构造 AQS 的 state 为 permits。当执行任务的线程数量超出 permits，那么多余的线程将会被放入等待队列 Park，并自旋判断 state 是否大于 0。只有当 state 大于 0 的时候，阻塞的线程才能继续执行,此时先前执行任务的线程继续执行 release() 方法，release() 方法使得 state 的变量会加 1，那么自旋的线程便会判断成功

有不准确的地方。多余的线程将会被放入等待队列 Park 后，不会再自旋判断 state 是否大于 0，而是等其他线程调用 release() 后，通过 AQS 的 doReleaseShared() 方法唤醒。

感谢指出，这样描述是不是更合适一些了：

Semaphore 基于 AQS 实现，用于控制并发访问的线程数量，但它与共享锁的概念有所不同。Semaphore 的构造函数使用 permits 参数初始化 AQS 的 state 变量，该变量表示可用的许可数量。当线程调用 acquire() 方法尝试获取许可时，state 会原子性地减 1。如果 state 减 1 后大于等于 0，则 acquire() 成功返回，线程可以继续执行。如果 state 减 1 后小于 0，表示当前并发访问的线程数量已达到 permits 的限制，该线程会被放入 AQS 的等待队列并阻塞，而不是自旋等待。当其他线程完成任务并调用 release() 方法时，state 会原子性地加 1。release() 操作会唤醒 AQS 等待队列中的一个或多个阻塞线程。这些被唤醒的线程将再次尝试 acquire() 操作，竞争获取可用的许可。因此，Semaphore 通过控制许可数量来限制并发访问的线程数量，而不是通过自旋和共享锁机制。

[HoeYeungHo]

是的，我感觉这样子描述会更好！

[Snailclimb]

是的，我感觉这样子描述会更好！

好的好的，稳！