如果线程使用不同的键，是否需要一个并发HashSet？
假设我有一组从客户机发送到服务器的请求ID。服务器的响应返回我发送的请求ID，然后我可以将其从哈希集中删除。这将以多线程的方式运行，因此多个线程可以在哈希集中添加和删除ID。然而，由于生成的ID是唯一的（从线程安全的源代码，比如现在的AtomicInteger，它会针对每个新请求进行更新），HashSet是否需要是ConcurrentHashSet？
我认为这可能导致问题的唯一情况是HashSet遇到冲突，这可能需要对底层HashSet对象进行数据结构更改，但在这个用例中似乎不会发生这种情况。
共有1个答案
对因为哈希表的底层数组可能需要调整大小，当然也因为ID可能会发生冲突。因此，拥有不同的钥匙根本没有帮助。
然而，由于您知道ID正在增加，并且如果您可以在未完成的最大ID数量上有一个上限（假设1000个）。您可以使用上限和下限以及一个固定大小的数组，从最低键开始进行偏移索引，在这种情况下，您将不需要任何互斥锁或并发数据结构。然而，这种数据结构非常脆弱，因为如果您的上限超过上限，那么地狱就会崩溃。因此，除非性能受到关注，否则只需使用Con电流tHashSet。
-
假设： 只有一个特定的线程设置了某个引用字段（不是长或双精度，所以写入它是原子的） 有任意数量的线程可能会读取同一个字段 稍微陈旧的读取是可以接受的（最多几秒钟） 在这种情况下，您需要挥发性或原子参考或类似的东西吗？ 该条指出： 如果您严格遵守单一写入器原则，则不需要内存障碍。 这似乎表明，在我描述的情况下，你真的不需要做任何特殊的事情。 我做了一个测试，结果很奇怪： 有时运行this会输出“线程
-
问题内容： 说我有一个全局对象： 有一个线程定期运行以从远程获取新编号并更新（仅写入）： 并且有一个或多个线程随机使用此全局变量（仅读取）： 您可以看到我不使用任何锁或对其进行保护，对吗？是否有可能引起问题的潜在问题？ 更新： 就我而言，读取线程必须实时获取最新的值并不是很重要。我的意思是，如果有任何问题（由于缺少锁定/同步而导致）使一个读取线程错过了该值，那就没关系了，因为它将有机会尽快运行相同
-
我有一张地图。假设: 多个线程正在访问此映射，但是每个线程只能访问映射中自己的条目。这意味着，如果线程T1将对象A插入到映射中，则保证没有其他线程将访问对象A。最后，线程T1也将删除对象A。 还可以保证没有线程会遍历映射。 这张地图需要同步吗？如果是，您将如何同步？(ConcurrentHashMap、Collections.synchronizedMap()或synchronized block
-
需要检测两个对象的状态，并且任务需要实时。run方法使用while（flag）循环通过更改flag=false来结束线程的生命周期。线程通常需要运行40分钟或更长时间。使用线程池将导致核心线程池耗尽，而任务将进入队列，因为每个线程将运行40分钟，每个线程的执行时间非常长且不固定，因此必须有许多线程无法及时响应。 我尝试使用新线程（runnable）。Start（）而不是使用线程池ThreadPoo
-
我对同步块有一些疑问。在提问之前，我想分享另一个相关帖子链接的答案，以回答相关问题。我引用彼得·劳里的同一个答案。 > <块引号> 同步确保您对数据有一致的视图。这意味着您将读取最新值，其他缓存将获得最新值。缓存足够智能，可以通过特殊总线相互通信（JLS不需要，但允许）该总线意味着它不必触摸主存储器即可获得一致的视图。 如果您只使用同步，则不需要Volatile。如果您有一个非常简单的操作，而同步
-
类AnagramGameDefault模拟一个字谜游戏。 submitScore（）应该重新计算位置，得分最高的位置为1，同一位置上可以有多个球员。 tester类：