LinkedBlockingQueue.poll方法测试（转载）

在产品中有碰到过使用 LinkedBlockingQueue.poll时超时很不准的现象，关键是这不是一般的不准，如果只是一点点不准的话也就勉强接受了，例如指定poll的超时时间为100ms，但最终执行.poll这段代码就花费了8000ms的现象，这篇blog就是展示下通过一段小小的代码来重现这样的现象，毕竟没有重现是无法证明为什么会出现这样的现象的。
由于在出现这个现象的时候有看到过OutOfMemory的错，虽然java进程没退出，但猜想可能是这个原因造成的，于是写了下面这段代码：

public   static   void  main(String[] args)  throws  Exception{
         long  beginTime = System.currentTimeMillis();
        Map < String,  byte [] >  cache = new  HashMap < String,  byte [] > ();
         for  ( int  i  =   0 ; i  <   1000000 ; i ++ ) {
            cache.put(String.valueOf(i), new   byte [ 500 ]);
        }
        CountDownLatch latch = new  CountDownLatch( 25 );
         for  ( int  i  =   0 ; i  <   5 ; i ++ ) {
             for  ( int  j  =   0 ; j  <   5 ; j ++ ) {
                Thread thread = new  Thread( new  TestThread(latch));
                thread.start();
            }
        }
        latch.await();
         long  endTime = System.currentTimeMillis();
        System.out.println( " 总共执行时间： " + (endTime - beginTime));
    }
    
     static   class  TestThread  implements  Runnable{

         private  CountDownLatch latch;
        
         public  TestThread(CountDownLatch latch){
             this .latch = latch;
        }
        
         public   void  run(){
            BlockingQueue < String >  queue = new  LinkedBlockingQueue < String > ( 1 );
             try {
                 for  ( int  i  =   0 ; i  <   5 ; i ++ ) {
                     long  beginTime = System.currentTimeMillis();
                    queue.poll( 100 , TimeUnit.MILLISECONDS);
                     long  endTime = System.currentTimeMillis();
                     long  consumeTime = endTime - beginTime;
                     if (consumeTime > 200 )
                        System.out.println( " 获取queue的时间为： " + consumeTime);
                    @SuppressWarnings( " unused " )
                     byte [] bytesNew = new   byte [ 25506000 ];
                }
            }
             catch (Exception e){
                ;
            }
            latch.countDown();
        }
        
    }

启动上面程序时，将jvm参数设置为-Xms640M -Xmx640M，运行后，应该会看到有很多queue.poll执行超过200ms的现象，甚至会出现8000ms的现象。
上面整段程序的写法就是用大量的小对象占据old generation，然后启动多个线程，每个线程运行的时候new一个大的对象，让其产生有可能直接从new generation分配到old generation，从而导致Full GC频繁执行，里面的byte数组的大小的原则为：塞满内存，产生Full GC，但又尽量不让应用出现OutOfMemory，或者说不出现过于频繁的OutOfMemory，避免jvm crash。
从上面程序的运行效果来看，当jvm内存消耗的很严重的情况下，poll的超时是没法准的，其实分析下原因，还是挺正常的：
1、jvm内存消耗严重的情况下，Minor GC和Full GC疯狂执行，导致了应用的执行不断的被暂停，因此当线程已经进入poll等待后，这个线程没有机会被执行，导致当其有机会执行时，早就超过了指定的超时时间，因此其超时不准并不是本身的机制导致的，而是jvm GC造成的多次暂停；
2、多次暂停的情况下，jvm需要不断的调度恢复线程，这需要消耗很多的资源，而且切换多了Swap空间很容易不够用，最终导致jvm crash。