世界因观察者而存在

很久很久以前，在一个很远很远的地方，那是大学一年级的暑假，数据库课程要求做课程设计。别人都做了什 么图书馆管理系统啊，仓库管理系统，XX管理系统，我却做了个土到渣都不掉的聊天系统，整个界面就和98上跑的QQ一个德行，最无耻的是还只能在局域网里使用。大一只做过控制台程序和windows桌面程序，突然发现SQLServer打开服务器可以在局域网里访问到，觉得发现了一种可能性，兴奋得跟捡到屎一样。这个聊天系统根本没有server，或者说SQLServer就是server，client直接连数据库，不管三七二十九把信息往里塞，再不停的刷新从数据库里取。就好像某些坏人，把钱藏垃圾桶里，另一个坏人来取走，把货留下，前一个坏人再来取走。彼此都不用相往来，除了塞垃圾和取垃圾什么都不用管。就这样这个系统还能共享文件，上传头像，一系列山寨功能。。。

后来觉得这个玩意太挫，server也应该是一个应用程序，应该是有生命的，而不仅仅是一个存放东西的，躯壳。在server程序体内，数据也应该有一些操作需要处理，新陈代谢，生生不息。。。server应该独立，不依赖与client，哪怕没有client来访问，server照样活得好好的。难道server存在的理由就是被client呼来唤去吗？我很为server感到不平，可惜后来发现事实还真是如此。

毕业后玩了玩Google Appengine，也做一个聊天系统，由于要处理断线情况，我用了一个心跳机制，就好像有一种坏人，他们引爆炸弹不是靠按下按钮，而是靠不再按按钮，以免被当场悲剧。同样的为了让client被当场击毙的情况下还能告知server我挂了，client必须不停的告诉server，我还活着。过一段时间没收到暗号就认为你丫死了。所以server要不停的检查众client是否还活着。

于是我很自信的在server端用了一个Timer，shit，刷出来满屏的出错信息，为首一条java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThreadGroup)，算是逮到头了。后来看了看文档发现Appengine出于安全的考虑不许建立新的线程。。。可怜的server，被剥夺了生命。当client无视他的时候，他什么都做不了。我可以专门写一个专门的client，不停的访问server，如同电击他的心脏，让他有生命的迹象。但是我很不喜欢这样的想法，那样也算是活着？

也许它根本就不应该活着？我曾经沉迷于印象主义的哲学，当古典主义关注实体本身的时候，印象派的大师们发现光才是事物的真相。存在并不是存在，而是被看见。我不是唯心主义者，我只是觉得，要是我看不见你，你存在不存在关我鸟事。当然这里说的看见，不单指用眼睛看，包括一切感官。不能被感知，是否可以存在，这是个很严重的话题，但是我压根就懒得去想它，因为不能被感知意味着不会对我产生任何影响，至于是否存在我觉得其实取决于存在的定义，而我可以说，存在就是能被我感知。我甚至不否认它可能被别人感知，而别人也可以说它存在，但在我的存在的定义下，它，对我来说，不存在。

光就好像是信息的传递，且不论server有没有生命，就连server存在不存在，client都是不关心的，只要我每次请求你能返回给我正确的值。事实就是这么冷漠，在模块化设计的思想下，一个模块也不会关心另一个模块到底如何，它只关心接口。只要每次我能得到正确的返回，哪怕给我这个返回值的，是一个坐在电脑前以每分钟490多次的速度敲击键盘的妖怪，我也无所谓。也许太阳在8分钟前已经熄灭，只是有一群超牛逼的太空萤火虫如蚁附膻的扑在慢慢冷却的核上，他们是如此牛逼以至于发出的光和阳光一模一样，地球上没有一个思维意识到这件事已经发生，除了我，但是我认为这毫无意义。

思来想去，server还确实就为client而存在。当没有client访问的时候，server甚至可以不存在，因此数据正确与否根本不重要。就好像小学的时候，老师不检查的作业就不做。但是我们必须保证server看起来和活的一样，保证在被访问的时候给出正确的数据。因此我在每次被访问到的时候把时间记下来，然后下次被访问的时候查看，如果时间间隔大于应该执行心跳检查的周期，就先做一次心跳检查，然后再该怎么着怎么着。稍加封装，我写了一个自己的Timer，和原来的Timer差不多，只是每次被访问的时候执行一次update，把时间更新一下，如有必要就执行run。也可以理解为这个Timer没有自己的生命，他只能寄生在主线程里面，而主线程处于半死不活的状态，属于那种戳一下动一下的傀儡，Timer的使命就是在他被戳动显示出生命征兆的那一刻，利用自己把server体内的数据清理一下。

client完全看不出来server是这样一个傀儡，他崇拜着server，每次请求都能给出正确的反馈。我得逞了，但是问题依然存在。世界因观察者而存在，server为client而生。这让我想起了薛定谔的猫。在client访问server之前，我们的随机数还没有生成，猫是死是活不得而知，并且猫既不是死的，也不是活的。只有当client访问server那一刻，决定了猫的命运，决定，而非发现。按照波函数的解释，打开箱子的一刻，猫的波函数从叠加态立即收缩到某一个本征态。那么问题就在于这一刻发生了太多的事情，因为我们的随机数不是一个简单的随机数，他需要通过亿万次运算才能最后决定猫的命运。在我们的世界一个时间点有多大我不得而知，我只知道，在计算机里，要是这个Timer在client请求之前做了太多的事情，就可能让client失去耐心，好在我暂时就需要这么一个操作，而且开销也不是很大。实际上对这个系统而言，在client来访的时候如果时间满足要求就检查所有client的状态仍然是奢侈的，因为一个client的请求只关心和他相关的client，每次client来访其实可以只检查和这个client相关的client的健康状况。但是这样有可能出现两个互相关联的client同时猝死，而使得两个client的后事无人料理。因此可以在每次检查相关client的时候捎带上一些别的client来检查。但是这毕竟是特殊情况，server本来应该反复执行的操作，延缓到client来访的时候，总归有可能出问题，只能是尽量去优化。比如如果client需要不停的做好几个互相独立操作，那么尽量让他们从时间上错开，做到一次client访问只做一个这样的操作。有的操作还与时间本身有关，那就还需要从递推公式得到通项公式。

比起给server以生命，也许这样更节省一点，至少server不会那么累。

因为生命，总是很累