更新危急值系统的时候，有个科室的教授打电话过来，我刚抓起电话来，就感觉到了那粗重的呼吸与满肚子的怒气：“你们检验科在我们科室装的是个什么流氓软件，危急值确认不了，关还关不了，赶快来给我删了！”

这个软件流氓也没有360杀毒软件这么流氓吧。

矛盾总是相对立存在的，出了问题，怕是双方都有责任的。

一、旧系统面临的问题。

一开始这个危机报告系统是别人做的，老是有科室跑过来问，你们那个危急值报告系统，为什么确认了，它还是弹出来呢，严重影响我们的工作，我无奈，只得把服务端给关了，过30分钟后再打开，开发商来了三四次，竟是不知道原因在哪里!

他写的这个危急值系统，服务端用的是多线程的Sokcet写的，等于有200个连接就有200个线程，这么多的线程导致cpu和内存用量激增，更重要的是一旦到了190左右，客户端就莫名的掉线，就怎么都上不去了。

还有一个重要的原因，那就是缺乏处理措施，医生就还得拿个本子去记录危急值，没有完全电子化。

二、新系统要怎么做。

怎么做，当然是推到重来呗。详细见：

危急值报告系统是如何炼成的？

其它不再赘述，讲讲异步Sokcet遇到的问题：

在这之前，讲讲同步Sokcet的黏包问题：数据接收的时候，假设你的数据包一个是1024那么大，黏包就是你一次接收的数据可能会是2048、3076那么大，换言之，即便你发送是一个个包发的，接收都还是有可能黏包，那么这个时候你就必须把接收到的数据处理成分开成一个个1024的包了。

异步sokcet也会黏包么？不知道，没有遇到过，但是它会断包！

比如：

acceptSocket.BeginReceive(stateObject.ReceivedBuffer, stateObject.Read, StateObject.BUFFER_SIZE, 0, new AsyncCallback(Read_Callback), stateObject);

StateObject.BUFFER_SIZE的大小是1044，那么你以为收到的数据就是1044那么大的，即便是黏包，也是1044的整数了。

最后发现，不会黏包，但是会断包！，收到包的大小可能是628和416两个包！！！！

我花了一个上午的时间，才发现是这个原因，一开始还以为是解析数据出错。

那么，为了收到完整的数据，我们必须这么写回调函数：
int read = stateObject.WorkSocket.EndReceive(ar);

if (read > 0)
{

stateObject.Read += read;

if (stateObject.Read >= 1044)
{
stateObject.Read = 0;

DataPacket dp = SocketHelper.BytesToPacket(stateObject.ReceivedBuffer);

this.ReceivePacket(dp, stateObject);

}
终于不报错了！

使用异步Soket后系统性能大大增强，这个是对比：

程序线程：16:212。
占用内存：28M：56M。
CPU:0%:2%。
让我想到Node.js，非阻塞的异步编程，是未来的王道。

三、软件是如何流氓起来的。

护士：你们那个软件，没有声音提示，不在电脑面前就听不到。

我：那就加一个电脑主机蜂鸣器的报警！

护士：你们那个软件不弹出来！

我：有这回事！那我偷偷在后台加一个截屏。

一看傻眼了，哪里是不弹出来，弹出来后，她把它拉到左侧隐藏起来了，然后继续干她的活。

第一次改进：判断窗口在左侧隐藏，就挪到中间来！

她的对策：往左拉一下，靠！又弹回中间了，那就往下面拉！

第二次改进：判断窗口是否居中，居中就挪到中间来！

她的对策：往左，往右，往上，往下拉，靠！还是弹到中间来，流氓！

吵吵微信朋友圈，请付款实名加入：