焦虑的程序员--关于final

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();