关于js的websock 和 java sock 之间的一些感悟。

js 的websocket 中的 onmessage 方法是在每次 接受到请求 或者是消息的时候就会进行接下来的调用。

而我们有这样的场景。

同样的服务器后台进行发送 4，096，000 bytes 的数据进行发送到前端客户端。每次只发送 4096bytes

有两种客户端 一种是 js 同websocket 写的 ，第二种是 用java  socket 写的。

现在假设 我们只要在前端在 读取 40，960 bytes 后就要随便执行一次 1+1；

如果是 java socket 的话，假设我们 inputstream 相应的实现类当中有一个方法叫 read40960（）的方法。

那么伪代码如下：

in.read40960();
1 + 1;

这样的代码。就会因为 read40960（）会阻塞等到。inputstream 的流当中有 40960 bytes 才会进行下一步的1+1的代码

那么一共计算得到 java 只会执行 1 + 1 的代码 100次

但是 如果是js 用 websocket进行 接收的话。因为每次发送 4096 就会调用一次

全部的两行代码。所以在js 中就会被调用 1000次。

可能如果有人会说。进行缓存判断

var buff ;
buff += in.read();
if(buff ==40960){
 1+1
}

这样 1+ 1不就只执行了 100次吗？

其实我这篇文章的重点不是 1 + 1 执行了多少次。而是在于 js 中的 没有java 中流进行阻塞的概念。js只会不断的根据逻辑判断避免，每次接收到请求的时候都会执行一遍逻辑代码。

加上js 是单线程 的，这样可能造成的时候就是 你执行1000此的简单逻辑判断，虽然每次只花了1毫秒，1000次就是1秒钟。

这样的设计，当你在做视频播放的时候可能就会出现问题。只有在1秒刷新一张图片，那是体验非常不好的。