Padded优化LinkedTransferQue并发性能是错误方向
在Grizzly中，自带了LinkedTransferQueue，和JDK 7自带的LinkedTransferQueue有所不同，不同之处就是使用PaddedAtomicReference来提升并发性能，其实这是一种错误的编码技巧，没有意义！ AtomicReference和LinkedTransferQueue的本质是乐观锁，乐观锁的在激烈竞争的时候性能都很糟糕，乐观锁应使用在非激烈竞争的场景，为乐观锁优化激烈竞争下的性能，是错误的方向，因为如果需要激烈竞争，就应该使用悲观锁。 以下是一个JDK中内置乐观锁悲观锁的对照表： 乐观锁 -----> 悲观锁 AtomicInteger -----> Lock + volatile int AtomicLong -----> Lock + volatile long AtomicReference -----> Lock + volatile LinkedTransferQueue -----> LinkedBlockingQueue 在激烈竞争中，LinkedTransferQueue的性能，远远低于LinkedBlockingQueue，使用PaddedAtomicReference优化也是一样的。如果不激烈竞争，Padded-LinkedTransferQueue和LinkedTransferQueue相比也没有什么优势。