java - 在线程之间共享数据 - 原子参考或同步

我正在制作一个2人视频游戏，并且在线程中oponent的位置得到更新，因为它有一个持续监听的套接字。我想分享的是位置和轮换。java - 在线程之间共享数据 - 原子参考或同步

由于这是一个视频游戏，我不希望主线程被阻塞（或者只是最短的时间），我不希望性能受到影响。因此，从我所看到分享这一信息正常的事情会是这样的

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

但是这将阻止，直到三个值（即绘制视频游戏相同）在主线程读取（或者将来会有更多的信息被写入）被写入，并且我读过同步代码非常昂贵（同样重要的是这款游戏也适用于android，因此性能非常重要）。

但我在想，也许有一个AtomicReference内的sharedInfo和消除同步会使它更有效率，因为它只会停止时引用本身正在更新（写不会存在，我会创建一个新的对象和把它放在atomicreference上），他们也说atom *使用硬件操作，并且比同步更有效率。

您认为如何？

来源

2012-11-17 dyeray

考虑为此使用队列，Java有一些很好的并发队列实现。查找java.util.concurrent中的BlockingQueue接口，以及实现它的人员。你有机会填补你甚至没有考虑过的实施策略。

你知道它之前，你会想沟通比你的线程之间公正立场，与队列，你可以在那里坚持不同类型的对象，也许在不同的优先级等

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

来源

2012-11-17 06:18:08

我曾考虑过使用队列，我认为这很适合发送像“我完成了游戏”，“我使用过这个/那个能力”这样的“事件”，但是对于这个职位你只是担心最后的发送位置，所以我在想，如果一个玩家比另一个玩家拥有更强的处理能力，那么它可能会淹没另一个玩家。即使你注意不要淹没你的对手，我认为它可能会浪费资源到你更新逻辑的地方，并且不得不提取6或8或者任何位置/角度元素，只使用最后一个。我的推理是否正确？ – dyeray

我认为你正在提出一些非常有效的问题。对于大多数人来说，有一种类型的队列可以实现它，比如有限的队列可以处理你所关心的旧更新的数量，阻塞或者非阻塞来处理洪泛......无论你选择什么，我都会建议你写一个很少有单元测试可以启动多个线程并且相互投掷东西。然后你可以玩不同的选项，看看他们的表现如何。如果您对Java中的并发编程感兴趣，请阅读Brian Goetz编写的“Java并发实践”一书。如果你不得不偷，它是很好的。 –

java - 在线程之间共享数据 - 原子参考或同步

回答

相关问题