看不见的程序中的神仙

在大多数人的心理，写程序那都是要求逻辑严谨，一就是一，二就是二，每一个判断，每一个逻辑那都是确定的

看大家写代码就是这样，每一行都极富有确定性，代码和代码之间的逻辑十分的严谨，特别是看那些有名的开源工程，简直是严谨到发指，你很难找到一行代码或者一个变量说想不明白为什么这么写（刚开始的时候当然是全都看不明白的，慢慢就好了）

再举两个旁证的例子

1，随机数，普通人想想随机数嘛，就是随便取呗。但对于逻辑严谨的理工男来说，随机数可不随便，我们一定要想办法生产出真正随机的随机数，为此我们要先定义随机，什么叫随机，满足什么样的条件才叫随机，结果就搞出了个什么随机性三标准，高举标准的大旗，坚定的走在迈向随机的大道上

2，神仙数，写过程序的可能都知道神仙数这个概念，代码中出现的常量，通常被认为是不好的

“说，为什么这里要写3，你收了3多少回扣”

可见对这种说不清来源的内容（通常是数字）在编码界很不受欢迎

 

什么？这个失败还要重试，我怎么知道？这是业务配置，自己配吧

这是不是很熟悉

 

作为程序员通常都不喜欢这种不确定性的东西，特别是经验，统计。经验和统计就代表一定有特例，我写的程序竟然不能完美的解决所有情况，还不如不做，这是很多人的一种想法

然而当我们对程序，对架构，对计算机有了更多的了解的时候，就会发现程序不仅要解决确定性的问题，还要想方设法的降低不确定性的风险，而经验和统计恰恰是我们面对不确定性风险的最大帮手

 

上面说到了神仙数，就借用这个名字来说说我们周围习以为常的这些神仙们（挑选举例）

先请出大神仙

三次握手

三次握手的详细定义点这里，这就是为了网络通信时确定网络是否联通用的

简单的说就是

我喊你

你听见我喊你了，你就冲我喊一声“我听见了”，然后等我回喊

我听见你喊的“我听见了”，再冲你喊一声“我知道你听见啦”

这时咱俩就都可以认为咱俩互相喊对方听得见了，接下来咱俩就可以对话啦（很多抗战电影里老式电话的通话也会有这个情节，“喂，长江长江，我是黄河”。。。）

有没有奇怪为什么是三次，不是四次，五次

我第一次听到三次握手的概念的时候就很奇怪了

因为信息不对称，所以即使第三次我喊完了，我也无法保证你能收到第三次的喊话啊，我凭啥不收到你的确认就认为就可以了呢？

从信息不对称的角度讲，这样的对话就算持续无数轮也无法保证下一次就100%成功（一切不决问量子力学）

那么为什么我们只要三次就可以了，这都成了一个伟大的术语

这个我们通过看一些计算机网络的教材就能大概知道原因

大致内容是：不到三次握手，之后传输的成功率完全无法得到保障，而通过三次握手，之后传输的成功率就已经非常高啦，再多次的握手也只是在这个很高的成功率上再加上一点点（再加也加不到100%），但是对于网络来说会增加一笔不小的开销，提升这么一点成功率，代价是网络开销增大很多，这不划算嘛

 

再请出小一号的神仙

JVM对象升级制度

研究过JVM内存分布的都知道，JVM对于管理的内存对象有一套严格的升级制度，通常情况（G1除外）JVM的Heap分为年轻代和老年代，年轻代里面有两个survivor，内存对象就在这两个survivor间，左手倒右手，右手倒左手，足足倒16次还在的对象就能荣升为老年代了，变钉子户了，只有full gc才能收拾掉

为什么是16次呢，虽然java执行也给了参数可以调，但并不是所有人都知道，大部分人都是用默认的，就算知道了，很多也都保持默认，16次升级

忘记在什么材料上看的了

依稀记得是这个数值是统计的结果，是根据大家的使用情况进行统计，16次就能保证很高比例（记得是在95%以上）的对象在普通gc的时候被干掉，减少进入老年代当钉子户的机会

具体16这个数应该就是根据收益和代价评估出来的一个结果

 

同一重量级的神仙还有

JAVA锁升级制度

JAVA的锁都会在内部经历自旋，偏向，轻量级，重量级这样一个升级的过程

这个升级的过程是人为不可控的，写java代码的人也不能设置说我现在这个锁就是一个偏向锁，或者就是一个重量级锁

这些锁都会在执行期的时候根据资源的争抢情况来经历这个升级过程

为什么会有这样的一个锁升级过程，而且是自动的，编程人员都控制不了

当锁从自旋升级的时候，需要自旋一定次数，这个次数是怎么定的，为什么这么定

这个跟上面一样，都是来源于具体使用的统计或经验，绝大部分的锁自旋就够了，能够升级到偏向的就不多了，再能够升级到轻量甚至重量的就更少了

自旋次数的设定能够保证绝大多数都停留在自旋，而且还能保证自旋所消耗的CPU资源也不会太多

 

这些都不是非黑即白的世界，都是通过统计通过经验，在确定和不确定上，在通用性，可用性和易用性上取得平衡

看了这些神仙们，再说回我们的软件设计和开发，真正的勇士敢于直面不确定的因素，就和交通一样，一定有确定的高峰低谷，也一定会不确定的突发高峰突发低谷，我们的系统不能仅仅是信号灯，还要借助经验和统计的力量，让他们成为为交警来调节，帮我们找到一个最合适的投入产出比

 

PS：也许有人会说这些都是很底层的，那么应用层有没有呢？一定是有的

大家可以自己思考一下，我也抛个砖

为什么HDFS默认块文件存三份？机器越多，三份是越可靠还是越不可靠呢？

 

欢迎关注公众号，共同交流，共同进步