焦虑的程序员--关于interrupt

睡

/**
	 * 实现这个接口的家伙是某个“服务组件”，既然号称“服务组件”也就是能向外提供若干个长时的服务逻辑实例。
	 * 嗯“长时”~~~~，这里是靠轮询来搞定了。但是具体的服务逻辑还是要规范的，此方法中就定义了“所启动的”具体服务逻辑。
	 * 
	 * 
	 * 而要注意了：“所启动的具体服务逻辑”必须满足：
	 * 		该方法中不执行任何不可控的长时逻辑：
	 * 			1.任何可能的block都应有类似的超时返回机制去约束。（超时返回，对应的现有情况：有blocking的IO操作存在，但设置了超时）
	 * 			2.或者可以证明此方法不可能长时间被trap住，无法返回。	（自然返回，对应的现有情况没有长时blocking的IO操作存在）
	 * 			3.或者可以证明，即使在被trap住的情况下，仍然可以自我执行可控周期内自我状态监听，从而可以“自我引导”结束返回。	（可轮询到中止信息后返回）。
	 * 		
	 * 		由于java对interrupt()的策略是非抢占式的，所以如果设计上考虑了线程中断的场景，那么是应该可以优雅退出的，但是关键是不知道上层业务逻辑是否很好的做了线程中断的处理。
	 * 
	 * 
	 * 长时间不返回又不可控的方法设计，是在任何一个业务层都应该尽量避免使用的，这样会造成当前执行资源无法响应设计中的系统信号，但是超时机制的加入会不会给系统造成不可忽略的效率负担呢？
	 * 
	 * 永远记住：Code pass占用的执行资源不一定自家的，执行资源很可能要重用的，所以任何层面的不可控的长期占用都是应当被禁止的。否则系统结束的“优雅”目标就很难达到，因为让其他服务实例来终结当前
	 * 服务实例，肯定不可能做到对具体业务的无侵害。
	 * 
	 * 
	 * 使得服务实例停止的可能只有两种，第一种可能是相应的“服务组件”STOPED了，第二种可能是方法内自己举起令旗了。
	 * 该方法的外部轮询会尽量吸收所有异常，所以如果服务实例内部有不可解决的问题时请举起令旗自觉终止该实例。
	 * 我们只是尽量吸收哦，如果系统跑崩了，内存溢出了等问题不在考虑范围内~！这个还在研究中。但是真出了这种问题，更多是service内部逻辑的问题。
	 * 
	 * @param 	currentInstance 当前服务实例的令旗，
	 * 			如果当前服务实例是直接dispatch到一个线程的（ThreadPool也是个服务组件啊），那么在服务实例结束后，这个线程也就结束了。
	 * 		  	如果是dispatch给一个线程池，那么按照线程池的语义，当前服务实例占用的线程资源就应该是被释放掉。
	 * 		  	另外这个令旗应该是具有"ThreadLocal"语义的，也就是当前运行的线程“一人一份”，请用各种方式确保这点吧（最贱的方法就是在run（）方法里new一个）
	 * @return 
	 */
	protected abstract void doServiceRoutine(ServiceInstance currentInstance);