Disruptor适合这种场景吗

今天在做性能测试，用到了线程池，结果发现线程池老是出现等待队列，结果跟踪下来是因为保存数据库这一步花费的时间比较长，所以就想保存数据库的操作用异步进行处理，刚好看到了jdon在介绍Disruptor这个框架，也是一个处理并发的框架，就是不知道适不适合这种场景。因为还没来得及了解一下这个Disruptor，所以先在些了解一下情况。

2012-08-26 13:16 "@chanball"的内容
线程池老是出现等待队列 ...

搞清楚线程池等待的瓶颈在哪里，当然可以使用Disruptor等异步方式消除因为后面线程等待导致前端响应缓慢或停滞的现象，将前端响应和后端处理分离。

2012-08-27 10:40 "@banq"的内容
搞清楚线程池等待的瓶颈在哪里，当然可以使用Disruptor等异步方式消除因为后面线程等待导致前端响应缓慢或停滞的现象，将前端响应和后端处理分离。 ...

主要就是数据库响应或网络不稳定时会出现这个等待，所以这部分有必要做异步处理，但是查了下disruptor的资料很少呀。下载的源码也没有demo。

2012-08-28 09:49 "@banq"的内容
demo ...

晕，JDK5不支持？呵呵，搞了半天，原来disruptor连jdk1.5都不支持呀，白搞了
[该贴被chanball于2012-08-28 20:02修改过]

2012-08-27 10:40 "@banq"的内容

顶一下
2012-08-26 13:16 "@chanball"的言论
线程池老是出现等待队列 ...


搞清楚线程池等待的瓶颈在哪里，当然可以使用Disruptor等异步方式消除因为后面线程等待导致前端响应缓慢或停滞的现象，将前端响应 ...

disruptor内部不也是一个队列嘛 如果数据库一直堵塞的话 使用disruptor也没太大作用吧？

2012-08-28 17:14 "@mistbow
"的内容
disruptor内部不也是一个队列嘛 如果数据库一直堵塞的话 使用disruptor也没太大作用吧？ ...

可以这里理解吧,disruptor中的生产者如果有一个需要等待很久才能完成,那么消费者是必须一直等待的,

而且从disruptor的例子中,他只能支持多个消费者一个生产者(后面有没有更新我就不懂了,不过如果他没有修改其RingBuffer读写原理的话,是不可能支持多个消费者的) 不过RingBuffer还是很棒的东西的