java - 在线程之间共享数据 - 原子引用或同步答案

【问题标题】：java - sharing data between threads - atomicreference or synchronizejava - 在线程之间共享数据 - 原子引用或同步
【发布时间】：2012-11-17 05:44:39
【问题描述】：

我正在制作一个 2 人视频游戏，并且对手的位置在线程上更新，因为它有一个持续监听的套接字。我要分享的是位置和旋转。

因为它是一个电子游戏，我不希望主线程被阻塞（或者只是尽可能少的时间），我不希望性能受到影响。因此，从我所看到的分享这些信息来看，正常的做法是

class sharedinfo
{
   public synchronized read();
   public synchronized write();
}

但这会阻塞主线程中的读取（与绘制视频游戏相同），直到写入三个值（或将来写入更多信息），而且我读过同步非常昂贵（还有一点很重要，说这个游戏也是安卓版的，所以性能很重要）。

但我在想也许在 AtomicReference 中包含 sharedInfo 并消除 synchronized 会使其更有效，因为它只会在引用本身被更新时停止（写入不存在，我会创建一个新对象并将它在 atomicreference 上），他们还说 atomic* 使用硬件操作并且比同步更有效。

你怎么看？

【问题讨论】：

【解决方案1】：

考虑为此使用队列，Java 有一些不错的并发队列实现。在 java.util.concurrent 中查找 BlockingQueue 接口，以及谁实现了它。您可能会发现您甚至没有考虑过的实施策略。

在不知不觉中，您将希望在线程之间进行通信的不仅仅是位置，并且通过队列，您可以将不同类型的对象放入其中，可能具有不同的优先级等。

如果在您的代码中尽可能多地使用接口（例如 Queue 或 BlockingQueue）（即除了构造特定实例的地方之外的任何地方），那么更换您正在使用的确切类型的 Queue 真的很容易，如果您需要不同的功能，或者只是想玩玩。

【讨论】：

我曾经考虑过使用队列，我认为它非常适合发送“我完成游戏”，“我使用了这个/那个能力”之类的“事件”，但对于你的位置只担心最后一个发送位置，所以我在想如果一个玩家比另一个玩家有更多的处理能力，它可能会淹没另一个。即使您注意不要淹没您的对手，我认为到达您更新逻辑的地方并且必须提取 6 或 8 个或任何位置/角度元素并且只使用最后一个元素可能会浪费资源。我的推理正确吗？
我认为您提出了一些非常有道理的担忧。对于其中大多数，有一种队列可以实现它，例如有界队列用于处理您关心的旧更新数量，阻塞或非阻塞处理泛滥......无论您选择什么，我都建议您编写一个很少有单元测试会启动多个线程并互相扔东西。然后你可以玩不同的选项，看看它们的表现如何。如果您对 Java 中的并发编程感兴趣，请阅读 Brian Goetz 的《Java Concurrency in Practice》一书。必要时偷它，那很好。