LF模式是个坑，一个小小的失误就可能使你的网络处理瘫痪，Ice就很好地展现了出来，换句话说，Ice中间件或是LF模式就是一个坑，如果你一不小心。
LF模式的官方论文中，论述了此模式用于高性能网络并发模式，使用的是系统的隐式队列，也就是Reactor复用多路IO，（如果是select的话，还是会将事件收集到一个显式队列），每次只有一条线程可以有一次机会成为leader访问这个队列，从队列取出事件后放弃leader，同时唤醒另一线程（如果还有follower线程的话）；注意这时的线程既不是leader也不是follower，它就可以处理事件，一般就是同步非阻塞读写，然后处理这个请求（通常来说就是dispatchFromThisThread）。当上面的工作结束就，才会作为follower等待成为leader，如果没有leader的话就会马上成为leader。在这种模式中，称为LF模式有点误导，因为实际上是三种状态，LPF，Leader，Process，Follower，状态机为 L->P->F->L->...。Follower状态的线程阻塞等待着Leader离开Leader状态去Process，从而唤醒可能的Follower状态的线程。被唤醒的Follower线程状态变为Leader，成为线程池中唯一当前有权操作队列的线程，要么阻塞在空队列，要么取出队列一个事件离开Leader状态去Process。线程池线程当Process完事件后才会状态变为Follower，或者阻塞等待Leader的唤醒，或者自动成为Leader。状态机就为 L（block on event queue）->P->F->（block on followers queue）->L ...。在这种模式下的线程池中，最多只有一个线程在Leader状态，并且只有这个Leader线程可以阻塞在IO事件队列，其它线程要么在Process状态处理事件，要么就是在Follower状态等待成为下一个Leader。当没有IO事件的时候，就只有一个线程在Leader状态阻塞在IO事件队列，其它线程都结事了事件的处理，并在Follower状态阻塞等待Leader线程释放信号。
通常用来衬托LF模式的，就是sync/async模式，并且都会举例Manager-Workers线程池。Manager负责将队列的事件指派到空闲Worker线程进行处理。Worker线程被唤醒处理完事件后再次阻塞等待Manager唤醒。当没有事件的时候，Manager阻塞在事件队列，Worker线程阻塞等待Manager线程唤醒。这种线程池有一个固定线程去阻塞在事件队列。并且每次Manager唤醒Worker都要通过堆来传递事件。（Manager从事件队列取出一个事件写入到堆内存，Worker从堆内存读到自己的栈，然后处理栈上的这个事件；而Leader从事件队列将一个事件读到自己的栈，再就唤醒其它Follower，然后处理栈上的这个事件。）当Manager线程不负责Reactor复用多路IO的情况，在空闲时发生了一次IO事件必须跨线程写入Manager线程的事件队列，并唤醒Manager线程，然后Manager线程唤醒Worker线程去处理事件。而LF模式线程池，Leader从系统的多路IO复用分离函数中返回，唤醒一个Follower，然后自己去处理事件。这样一比较就是Manager-Workers线程池进行了两次线程唤醒，而LF模式线程池只有一个线程唤醒（这里必须要公正，Leader是之前就被唤醒经历消耗了一次切换），事件在Manager-Workers线程池需要多次拷贝。
那么为什么LF模式不心就会踩坑，而Ice的设计就让体会这个坑。
问题在于如果LF模式线程池的线程进行Process阻塞等待IO响应，而所有的线程都在Process过程中阻塞等待IO响应，更重要这些被等待的IO应用在这个线程池的Reactor，就会再也没有线程成为Leader去多路IO分离函数中读取IO事件。这时候这个LF线程池就会瘫痪不工作。Ice中间件会让你深深体会这种痛。Ice采用ActiveObject模式进行OBR对象代理请求。控制线程调用proxy请求返回一个future，阻塞等待future。Communicator的clientThreadPool负责Reactor，收到请求的response后就向future发信号，从而唤醒这个response对应的future阻塞住的控制线程。这种情况下使用ORB对象代理请求的线程与网络Reactor线程池独立，负责Reactor的LF线程池不会被其它逻辑影响。但是在LF线程池中进行ORB对象代理请求呢？问题就来了。你的LF线程池随时都可能瘫痪掉，只要你不小心。极端地，LF线程池只有一个线程，这个线程在Process事件时，进行了ORB对象代理请求，阻塞等待future。Good Job!! 这个线程池中唯一的线程就永远不会再有机会成为Leader去取出远端的response的IO事件，去唤醒这个阻塞住线程的future了。这还不容易解决，都说是线程池，那会只有一个线程的呢。我们让这个LF线程池添加到两个线程，第一个线程取出事件唤醒第二个线程，然后自己处理事件时，进行了ORB对象代理请求，阻塞等待future；第二个线程成为Leader阻塞在多路IO分离函数，并在远端response到来时，从分离函数返回，得以唤醒了阻塞第一个线程的future。但是很不幸，第二个线程在等待到response到来之前，收到其它IO事件，而处理这个事件却进行了ORB对象代理请求，阻塞等待future。汗，LF线程池都被阻塞在future，future又等待IO事件。再往下演绎，不论LF线程池有多少线程，只要你的处理逻辑中进行了同步阻塞的ORB对象代理请求，都会使你的Ice网络处理瘫痪，瘫痪的原因是LF线程池瘫痪了。Ice的Server端线程池默认就在当前线程进行请求的dispatch，如果你在实现你的服务的时候必须依赖其它ORB对象代理请求时，你就要小心了，你可能因为这样而阻塞掉所有Communicator的Server端LF线程池，至使网络Reactor瘫痪。如果你使用了bidirection connection来提供callback的饲服，要是你在callback的实现中依赖了其它ORB对象代理请求时，你同样也要小心了，你可能因为这样而阻塞掉所有Communicator的Client端LF线程池，至使网络Reactor瘫痪。Ice为了避免，会默认为每个连接加上一个计时器，让连接自动断开。但是我们还是有应用场合希望连接长九不断开，关闭这种机制，这时就要小心了。再者就是，即使你所有的ORB对象请求代理都用异步方式（ami，amd）进行编程，但是悲剧的是你无法干涉到你依赖的其它人函数没有进行同步阻塞的ORB对象代理请求。
