Zzzz
/**
*
* 使用final修饰变量是为了强调在调用该变量的上下文中,该变量是保证不变的,
*
* 场景:需要将一个同步执行的上下文拆分成分阶段异步执行的上下文,
* 保证上下文环境的“等效”是必要的,做到即使出现“刻舟求剑”的情况,
* 也不是由于上下文的异步拆分引起的。
*
* 上下文的等效的判定:
* 1: 外部引用的资源等效,设置具有final语义是保证等效的“
* 必要但不充分条件”,
* 因为在上下文中引用资源的状态还是可能会有其他形式的改变,
* 而这种改变是否会对“异步改造”的产生影响,
* 需要在“上下文运行流程等效”上进行分析。
* 2: 上下文运行流程等效
*
*
* Tip: 分析一个问题的时候,会有一下关系存在,
* 判断“场景A 是 场景B 的问题”这个关系是否成立。
* 判断这个关系是否成立的过程应该分为两步:
* 1. “就当下系统事实情况”,判断场景A是否和场景B“独立”,
* “独立”的判断可以有很多标准,
* 可以是统计上表现的,也可以是逻辑上的相互制约等
* 如果是独立的,则问题的关系不成立,
* 也就是不应该在场景B的改造中考虑场景A
* 2. 如果相互不独立,则需要具体情况具体分析了。
* 之所以要求有步骤一,是因为在现实中有太多的“伪问题”存在,
* 将两个本来相互独立的现象硬放在一起,
* 说是一个问题,非常具有迷惑性。而且是诡辩中经常使用的伎俩,
*制造“伪问题”:
* 注意“就当下系统的实际情况”的前提,
* 之所以有这个前提是因为我们必须从实际情况出发,
* 因为如果没有这个前提,那么在一个假设的情况中,
* 将两个独立的事情搅和修改成非独立的,是一件很容易的事情。
* 如果这种辩解出现了,首先要提醒的是,这种假设的场景是否是事实,
* 如果不是,问是否觉得这种假设很有道理,
* 让大家很happy,
* 以及是否非要在当前的场景比较中强加进来是否是合适的时机。
*
*
* 实战:
* 问题: 可能有人会问,即便是引用的变量被设置成了final了但是对象实例还是无法保证不变啊?
* 回答: 这确实是一个事实场景,但是即使不做异步改造(也就是在同步的上下文下),这个场景同样可能会发生。
* 此时应判断“即便是引用的变量被设置成了final,但是对象实例还是无法保证不变”场景同“上下文的异步改造”场景
* 是否是独立的,如果是独立的,就没有必要在异步上下文改造的过程中考虑他。
*
* 也许更好的提问方式是“对final的对象的内部改变进行控制”场景同“上下文的异步改造”场景是否独立,
* 此时的回答是: 不是独立的,“对final的对象的内部改变进行控制”场景 是 “上下文的异步改造”场景 的问题
* 关系成立,因为控制策略会因为同异步的不同而改变。这也是我们在改造中应当特别注意的。
* 并且有些控制场景在异步改造的过程中会异常困难,此时可能会发现,
* 资源本身都必须建立针对某种操作的版本控制机制。
* 由以上分析可以看出,设置final的根本价值在于缩小了考虑问题的范围。确立了分析问题的步骤:
* 1,界定具有final语义的资源
* 2,结合1中资源的状态变迁,分析上下文运行流程等效性,给出具体方案
* 值得一提的是,在异步的环境中,即使我们可能很难要求资源不发生状态变化(
* 就像false share现象),也应该思考下,在这个不可测的变化中,
* 所真正关心的那部分信息变化了么?如果没有,那世界依旧还是美好的。
*
* 删了可惜的注释,存在blog里吧
*/
private final ServiceInstanceKeeper serviceInstanceKeeper = new ServiceInstanceKeeper();