The service side originally had a timed task to handle the messages in a collection ArrayList. Because the processing message is considered to be the FIFO principle, the optimization should be considered instead of concurrentlinkedqueue at that time did not carefully in-depth study of the collection on the rush to the online. The result just came online the next day it was a problem. Service-side optimization has evolved into a flaw, fortunately timely return of the version, the consequences are not very serious.
Back off. A simple test code for Concurrentlinkedqueue is as follows:
Import Java.util.concurrent.ConcurrentLinkedQueue; Import Java.util.concurrent.CountDownLatch; Import Java.util.concurrent.ExecutorService; Import java.util.concurrent.Executors; public class Concurrentlinkedqueuetest {private static concurrentlinkedqueue<integer> queue = new Concurrentlinkedqueue<integer> (); private static int count = 100000; private static int count2 = 2; Number of threads private static Countdownlatch cd = new Countdownlatch (COUNT2); public static void Dothis () {to (int i = 0; i < count; i++) {Queue.offer (i)}} public static void Main (string[) AR GS) throws Interruptedexception {Long Timestart = System.currenttimemillis (); Executorservice es = Executors.newfixedthreadpool (4); Concurrentlinkedqueuetest.dothis (); for (int i = 0; i < Count2 i++) {es.submit (New Poll ());} cd.await (); System.out.println ("Cost time" + (System.currenttimemillis ()-Timestart) + "MS"); Es.shutdown (); The static class Poll implements Runnable {@Override public void run () {// while (Queue.size () >0) {while (!queue.isempty ()) {System.out.println (Queue.poll ());} cd.countdown ();} }
Run Result:
Costtime 2360ms
When you switch to while (Queue.size () >0)
Run Result:
Cost Time 46422ms
The result is so different, look at the Concurrentlinkedqueue API original. Size () is to traverse the collection, no wonder so slow, so try to avoid using size instead of IsEmpty ().
summed up, in the unit lack of performance testing, the requirements of their own programming more stringent, especially in the production environment is to be cautious.