LinkedList队列和线程安全

发布于 12-11 01:30 字数 580 浏览 0 评论 0原文

我有一个线程将对象 add() 添加到 LinkedList 队列中,另一个线程将 poll() 作为要处理的对象的队列。这是我在队列中使用的唯一两种方法。我从不遍历队列,也不在列表中间添加或删除对象。我无法想象两个线程相互干扰并以某种方式损坏数据的场景,但也许我的想象力根本就缺乏。

推送很少(每秒几次),但轮询非常频繁(每秒几千次)。我想知道同步 add()poll() 会受到多少惩罚。这是在 Android 上运行的。

编辑:我不是在寻找BlockingQueue;我阻塞在 I/O 上,而不是阻塞在队列中的对象上:

轮询线程上的 run() 方法会阻塞等待输出缓冲区中的空间变得可用。当空间可用时,它会查看队列中是否有任何对象在等待。如果有可用的,它会将其序列化到输出缓冲区中。如果队列为空(即poll() 返回null),则poll()是其他优先级较低的队列,并且如果全部为空,序列化“现在没有可用数据”消息。

I have one thread that add()s objects into a LinkedList queue, and another thread that poll()s the queue for objects to process. These re the only two methods I use on my queue. I never iterate through the queue, nor add nor remove objects in the middle of the list. I cannot think of a scenario when the two threads step on each other and corrupt the data somehow, but perhaps my imagination is simply lacking.

The pushing is infrequent (several times per second) but the polling is very frequent (a couple thousand times per second). I wonder how much of a penalty I get for synchronizing the add() and the poll(). This is running on Android.

Edit: I am not looking for a BlockingQueue; I am blocking on I/O, not on objects in the queue:

The run() method on the polling thread blocks waiting for space to become available in an output buffer. When space becomes available, it looks to see if it has any objects waiting on the queue. If one is available, it serializes it into the output buffer. If the queue is empty (i.e. poll() returns null), it poll()s other, lower-priority queues, and if all are empty, serializes a "no data available now" message.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

为你鎻心2024-12-18 01:30:03

Umn doesn't android have BlockingQueues? They are designed for exactly that scenario, no idea why you'd want to use anything else - can't get much more efficient..

琴流音2024-12-18 01:30:03

如果没有同步,您可能会遇到这样的情况:读取线程正在轮询刚刚添加到队列中的对象,并且列表尚未完全退出 add() 方法。

如果你查看源代码,可能会因为“expectedModCount = l.modCount;”而搞砸一些事情。因为在 modCount 实际修改之前,轮询的锁存器基于其下方的一行。

本质上,您的删除是在完美的时间发生的,可能有 1 个元素,同时添加了另一个元素,并且出现了错误。

为了防止这种情况,您可以将访问包装在synchronized(lst){}块中,或者可以使用并发类。我更喜欢并发队列,因为 poll 不必旋转——你可以有一个阻塞 take()。

您可能正在寻找:java.util.concurrent.ArrayBlockingQueue

ArrayBlockingQueue<String> que = new ArrayBlockingQueue<String>(100);
    que.add("");
    que.take();

Without synchronization, you may get the case where the reading thread is polling the an object that has JUST been added to the queue, and that the list has not quite finished exiting out of the add() method.

If you look into the source, it's possible to screw something up with "expectedModCount = l.modCount;" because the latch for the poll is based on a line below it before modCount is actually modified.

Essentially, your remove is happening at the perfect time, probably with 1 element, while adding another at the same time, and getting something wrong.

To prevent this, you can wrap your accesses in synchronized(lst){} blocks or you can use the concurrent classes. I would prefer the concurrent queues because poll doesn't have to spin -- you can have a blocking take().

You're probably looking for: java.util.concurrent.ArrayBlockingQueue

ArrayBlockingQueue<String> que = new ArrayBlockingQueue<String>(100);
    que.add("");
    que.take();
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文