【问题标题】:Java - extensive semaphore usageJava - 广泛的信号量使用
【发布时间】:2012-07-13 09:01:08
【问题描述】:

在我编写的服务器中,每个客户端处理程序对象都包含一个用于某些用途的信号量,因为可能有许多客户端处理程序 - 我想知道程序可以容纳的信号量数量是否有限制?

【问题讨论】:

  • Java 可能没有任何限制,但本机操作系统/硬件可能有。
  • @Santosh 如果正在创建信号量但它们中的大多数很少使用怎么办 - 操作系统是否对信号量实例的数量或在信号量上休眠的线程数量有限制?
  • 操作系统确实对创建的信号量对象的数量进行了限制,超过该数量您就不能让线程处于等待状态。看看这个link for windows
  • @Santosh 谢谢 - 小心将其发布为答案,以便我能够接受?

标签: java multithreading concurrency semaphore


【解决方案1】:

操作系统确实限制了应用层可以创建的信号量实例的数量。一个达到这个限制,没有更多的线程可以处于等待状态。此数字特定于操作系统。这里是link for Windows

【讨论】:

  • OS-Semaphore 和 java.util.Semaphore 之间存在差异。虽然操作系统级别的信号量数量有限制,但 java.util.Semaphore 在不使用时不会阻塞任何系统资源(除了一些内存)(即它是一个 POJO wrt.特殊的操作系统资源)。
【解决方案2】:

java.util.concurrent.Semaphore 是标准 Java 对象,因此与堆中的所有其他对象具有相同的限制。因此,只要您有足够的内存,实例化更多 Semaphores 应该没有问题。

我觉得奇怪的是,您需要如此大的数字,以至于您甚至会考虑这是否会导致问题。通常,并发程序只有少数几个关键部分必须由不同的信号量保护,并且 Java 中的大多数数据结构都有线程安全的替代方案,这比手动同步它们更容易。

【讨论】:

  • 大多数时候信号量没有被使用,但客户端处理程序仍然会在创建时分配一个信号量,因为在互斥体中必须执行特殊操作
  • 您是否考虑过同步该特殊操作?
  • synchronized - 除了提供互斥锁之外,还通过使本地 cpu 缓存无效来解决本地线程内存可见性问题,因为我的操作没有这个问题,使用同步并且使本地 cpu 缓存无效有点开销。
猜你喜欢
  • 2015-07-20
  • 2010-11-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多