tentativeprobe的博客

Zzzz[code="java"]/** * * 使用final修饰变量是为了强调在调用该变量的上下文中，该变量是保证不变的， * * 场景：需要将一个同步执行的上下文拆分成分阶段异步执行的上下文， * 保证上下文环境的“等效”是必要的，做到即使出现“刻舟求剑”的情况， * 也不是由于上下文的异步拆分引起的。 * * 上下...

睡[code="java"]/** * 实现这个接口的家伙是某个“服务组件”，既然号称“服务组件”也就是能向外提供若干个长时的服务逻辑实例。 * 嗯“长时”~~~~，这里是靠轮询来搞定了。但是具体的服务逻辑还是要规范的，此方法中就定义了“所启动的”具体服务逻辑。 * * * 而要注意了：“所启动的具体服务逻辑”必须满足： * 该方法中不执行任何不...

睡觉[code="java"]/** * 分发一个服务模版，从而启动一个服务实例, 单总数不能超过参考的上线。 * @return */ protected boolean createSingleServiceInstance() { //不能在这里做服务实例数量相关的策略控制，因为这个地方取不到比较准确的运行中的服务实例的数量值，取到的只是一个参考值。 ...

睡不着~[code="java"]/** * 根据“最小知识”原则，此处不做异常处理，因为没有足够的信息做处理，如果硬要处理会局限该接口的使用场景。 * 如果外围觉得有异常不可接受，可以自行处理。 * 资源回收在此也不合理，因为dispatch只是消息资源的使用方，而非拥有者，不具备销毁资源的权利 * 资源回收应该秉着谁生产资源，谁负责回收资源的原则。使用方没有任何...

睡不着.....~![code="java"]/** * 恩，为什么要有这个类呢，因为在做stop操作的时候，首先要“通知”所有的服务实例停止服务对其进行卸载，然后要再执行doStopProcess()释放资源 * 这个时候就需要有个对象能建立起服务实例和拥有他们的服务组件之间的一个信息通道。 * 以下方法都有同步操作，但是使用场景是服务实例的数量控制，不属于高并发场景，...