SessionDispatcher
Jerry来信问了一些有关SessionDispatcher的问题,在征得其同意后,将来信和回信贴在这里,希望能给大家一些帮助。
来信
你好,看了你的cindy觉得很有意思,看到他一直在进步,也很让人高兴。
看了新出的cindy3.0a2里面的代码,和3.0a1做了一下比较,发现了一些不同,所以想请教一下你的想法
你的SessionDispatcher里面启动的是只有一个线程的线程池,很想了解这里能把线程池中的线程数目调大吗?
从我的理解应该是可以的,这样就形成了处理NIO常用的1-N的线程模型,不知道理解是否有误?
在Cindy3.0a1的HSHAReactor的start方法里面有如下的代码
在Cindy3.0a1的HSHAReactor的start方法里面有如下的代码
private synchronized void start() {
if (selectThread != null)
return;
if (selectThread != null)
return;
int minPool = CindyConstants.getMinThreadPoolSize();
int maxPool = CindyConstants.getMaxThreadPoolSize();
// keep event dispatched in order
if (minPool == 0 && maxPool == 0)
dispatcher = new DirectExecutor();
else
//Start a seperate dispatcher thread, maybe this will become a
thread pool.
dispatcher = Executors.newSingleThreadExecutor(threadFactory);
lastSelectTime = new ElapsedTime();
int maxPool = CindyConstants.getMaxThreadPoolSize();
// keep event dispatched in order
if (minPool == 0 && maxPool == 0)
dispatcher = new DirectExecutor();
else
//Start a seperate dispatcher thread, maybe this will become a
thread pool.
dispatcher = Executors.newSingleThreadExecutor(threadFactory);
lastSelectTime = new ElapsedTime();
这个dispatcher处理的都是selector相关的东西。但是在Cindy3.0a2里面这部分代码去掉了,是发现了什么线程问题吗?
3.0a1和a2的start方法上都有个synchronized关键字,里面启动了一个线程。
这样的话,在这个内部线程死掉之前,这个方法是不能被别的线程访问的,对吗?觉得这样的处理方法很tricky,呵呵。
请不吝赐教,谢谢!:)
回信
Jerry,
很高兴你对该项目抱有浓厚的兴趣,这里就你提出的问题做一些交流。
1.SessionDispatcher线程数的调节
SessionDispatcher的存在的目的并不是为了效率以及可扩展性,它存在的目的仅仅是为了保证结果的正确性,所以线程数没有调大的必要。
Cindy中同时存在着同步方法和异步方法。异步的比如Listener、Filter一系列机制都是用于处理异步情况的,在相应的事件完成后再通知应用;同步的比如Future.complete(),会在该任务完成后才从该方法中返回。
这里就牵涉到的问题就是:因为核心是异步的,如果应用在核心线程中调用了同步方法,则该同步方法将永远无法完成。
所以SessionDispatcher的作用就是使得真正的核心线程永远也到达不了应用层,所有应用层的事件都是由 SessionDispatcher中的线程来发送。同时,为了保证同步方法不阻塞SessionDispatcher,一旦应用层调用了同步方 法,SessionDispatcher就会通过内置的线程池来选择另一个线程发送消息。
举个例子。比如同时开启了10个Session,其中一个Session在sessionStarted事件中进行数据发送,并调用了Future.complete方法。
session.addSessionHandler(new SessionHandlerAdapter() {
public void sessionStarted(...) {
session.send(someObj).complete();
}
});
public void sessionStarted(...) {
session.send(someObj).complete();
}
});
如果是核心线程进行事件的发送。那么调用complete后,这时并没有开始发送,所以线程被阻塞;并且由于核心线程被阻塞,真正的网络操作将永远无法执行,只能被一直阻塞。
如果只是单线程进行事件发送。那么调用complete方法后,事件发送线程被阻塞,但核心线程还是可以完成网络操作,并把操作完成的事件添加 到事件发送队列中。但是由于事件发送线程被阻塞,它也无法得到事件完成的消息,它也会一直阻塞在这里。并且,即使有办法恢复事件发送线程,但在它阻塞的过 程中,其他9个Session的消息也没有办法发送,这会极大的降低吞吐量。
目前的做法还是单线程分发事件,但一发现应用调用阻塞操作,就通过一个线程池获取另一个线程继续后面的事件分发;等到原线程从阻塞操作中恢复,再把线程放到线程池中。是Lead-Follows模型的应用。
2.Reactor的start方法上使用synchronized关键字
在该方法中使用synchronized关键字,并不会使在该方法中开启的线程也必须要拥有该锁。所以内部线程不死掉,该方法也能被调用。
3.Reactor的线程池调节
a2对这个的改动并不是线程问题,而是实际测试中发现这些代码并没有意义,不管在单CPU还是多CPU的情况下,效率只有降低,而没有提高,所以才去掉了这部分的代码。
至于1-N的线程模型,由于Filter机制的提供,应用可以根据自己的需要做更细的调节。比如通过自己实现的Executor,再 加上ExecutorFilter做N个分派线程;或者仅仅对messageReceived事件进行池化分派,等等。这些完全取决于应用自身的需要。但 是需要注意的是,一旦通过自己实现的线程池进行分派后,在进行同步方法的调用时就要注意尽量不影响其他异步操作的进行。