java.util.ConcurrentLinkedQueue [英] java.util.ConcurrentLinkedQueue

问题描述

我想使用java.util.ConcurrentLinkedQueue作为Servlet的非持久队列。
这是类javadoc中的blurb。

基于链接节点的无界线程安全队列。当许多线程共享对公共集合的访问时，ConcurrentLinkedQueue是一个适当的选择。此队列不允许空元素。

现在想象我有1000个并发请求在servlet上，每个线程将需要enque对象进入ConcurrentLinkedQueue。从描述，我应该得出结论，它将没有处理负载问题？我需要的保证是：

1. 我自动接收线程安全保证，而不需要自己进行同步。


2. 如果流量负载超过1000个并发请求，我将不会丢失任何请求。

p>

解决方案

你本质上是要求三个不同的问题（其中两个是明确的，一个是隐含的。）在这里， / p>

1。如果我使用 java.util.ConcurrentLinkedQueue ？我需要进行自己的同步吗？

Atomic对并发集合的操作将同步。换句话说，对队列的每个单独调用都保证线程安全，而您没有采取任何操作。什么是不保证线程安全是您对集合执行的非原子操作。

例如，这是线程安全的您的任何操作：

  queue.add（obj）; 
  

或

  queue.poll（obj）; 
  

对队列的非原子调用不是自动线程安全的。例如，以下操作不自动线程安全：

  if（！queue.isEmpty ）{
 queue.poll（obj）; 
} 
  

最后一个不是线程安全的，因为很可能在时间isEmpty被调用，并且调用时间轮询，其他线程将从队列中添加或删除项目。执行此操作的线程安全方法如下：

 同步（队列）{
 if（！queue.isEmpty ））{
 queue.poll（obj）; 
} 
} 
  

线程安全。非原子调用不是。

2。如果有1000个并发请求，我保证不会失去对 java.util.ConcurrentLinkedQueue 的调用？

因为这是一个无界的实现，所以无论同时发出多少请求，队列都不会丢失这些请求（因为队列的并发性...你可能会耗尽内存或者一些东西......）队列实现本身不会是你的限制因素。）在Web应用程序中，有其他机会丢失请求，但队列的同步（或缺少）不会是你的原因。

3。 java.util.ConcurrentLinkedQueue 是否表现良好？

通常，我们谈论正确性当我们谈论并发时。我的意思是，并发类保证它们是线程安全的（或者死锁，饥饿等）。当我们谈论这个时，我们没有对性能做任何保证（如何快速调用集合是的） - 我们只是保证他们是正确的。

但是; ConcurrentLinkedQueue是一个无等待的实现，所以这可能是你可以得到的性能。保证servlet的负载性能（包括并发类的使用）的唯一方法是在负载下测试它。

I want to use java.util.ConcurrentLinkedQueue as a non-durable queue for a Servlet. Here's the blurb from the javadoc for the class.

An unbounded thread-safe queue based on linked nodes. A ConcurrentLinkedQueue is an appropriate choice when many threads will share access to a common collection. This queue does not permit null elements.

Now imagine I have 1000 concurrent requests on the servlet, and each thread will need to enque an object into the ConcurrentLinkedQueue. From the description, should I conclude that it will have no problems handling the load ? The guarantee that I will need is that:

1. I automatically receive the thread-safe guarantee without needing to do my own synchronization.
2. I will not lose any requests if the traffic load goes beyond 1000 concurrent request.

Thanks

解决方案

You're essentially asking three different questions (two of them explicitly and one implicitly.) Here they are, with my answers:

1. Do I need to do my own synchronization if I use java.util.ConcurrentLinkedQueue?

Atomic operations on the concurrent collections are synchronized for you. In other words, each individual call to the queue is guaranteed thread-safe without any action on your part. What is not guaranteed thread-safe are any operations you perform on the collection that are non-atomic.

For example, this is threadsafe without any action on your part:

queue.add(obj);

or

queue.poll(obj);

However; non-atomic calls to the queue are not automatically thread-safe. For example, the following operations are not automatically threadsafe:

if(!queue.isEmpty()) {
   queue.poll(obj);
}

That last one is not threadsafe, as it is very possible that between the time isEmpty is called and the time poll is called, other threads will have added or removed items from the queue. The threadsafe way to perform this is like this:

synchronized(queue) {
    if(!queue.isEmpty()) {
       queue.poll(obj);
    }
}

Again...atomic calls to the queue are automatically thread-safe. Non-atomic calls are not.

2. Am I guaranteed not to lose calls to java.util.ConcurrentLinkedQueue if there are 1000 simultaneous requests?

Because this is an unbounded implementation you are guaranteed that no matter how many simultaneous requests to make, the queue will not lose those requests (because of the queue's concurrency...you might run out of memory or some such...but the queue implementation itself will not be your limiting factor.) In a web application, there are other opportunities to "lose" requests, but the synchronization (or lack thereof) of the queue won't be your cause.

3. Will the java.util.ConcurrentLinkedQueue perform well enough?

Typically, we talk about "correctness" when we talk about concurrency. What I mean, is that Concurrent classes guarantee that they are thread-safe (or robust against dead-lock, starvation, etc.) When we talk about that, we aren't making any guarantees about performance (how fast calls to the collection are) - we are only guaranteeing that they are "correct."

However; the ConcurrentLinkedQueue is a "wait-free" implementation, so this is probably as performant as you can get. The only way to guarantee load performance of your servlet (including the use of the concurrent classes) is to test it under load.

这篇关于java.util.ConcurrentLinkedQueue的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！