SignalR前后端进行通信时，出现了内存泄露

在做此需求之前，需要知道:
1、当前wafer功能已经用canvas实现了
2、die指的是图片中每一个小格子
3、当前正在工作的die用黄色进行高亮，已经工作过的die用灰色表示
4、几台基本每秒工作3个die
wafer图片：

最近在做一个需求，wafer在工作的时候，需要实时展示当前正在作业的die，已经已经作业过的die均高亮且实时展示。
当拿到这个需求的时候，我们需要考虑一下几个问题：
1、当前作业的wafer数据量比较大的时候，如何实时展示高亮的die
2、机台工作的die基本是每300毫秒工作一次，如何保证页面上的数据和机台数据是同步的

思路：
1、每工作一个die高亮展示就需要实时的刷新canvas，后来考虑到数据量较大时候，频繁操作canvas会造成浏览器崩溃，所以，最终解决方案是：只重新绘制需要改变颜色的die，不需要改变的就不动
2、数据实时同步问题：
2.1、首先是前后端如何进行通信，最开始是考虑用轮询的方式，但考虑到时效性及贷款资源问题就舍弃了，最终采用signalR进行实时订阅，实时推送。
2.2、从redis中订阅消息是以数组的形式还是以字符串的形式进行存储，假设一个工厂有1000台机器，每台机器都在工作，不断的往redis中存数据，可能会对redis的内存造成一定的压力，所以最终采用了字符串的形式

最终实现效果如下图所示：

在测试的时候，发现一个致命的问题：在采用signalR进行实时推送的时候，服务器莫名崩溃了
通过排查发现，服务器崩溃的原因是：内存耗尽，程序终止运行

内存耗尽明显就是内存泄露的问题，那么问题是出现在哪呢？
可能情况
1、前端出现内存泄露
2、后端出现内存泄露
后端：在经过几波优化之后，明确告诉我，推送的就是一个序列化之后的字符串，不可能出现内存泄露的问题
前端：如何前端出现内存泄露，那最直观的体现应该是浏览器变卡顿，直至浏览器崩溃，为什么会对服务器造成崩溃？
前端经过几天的验证，验证方法如下：
就是对Signal推送数据后的处理代码逻辑进行分配验证。看那一段代码造成内存泄露。
结果就是，每注释掉一段代码就会延缓服务器崩溃的时间，如果只是往前端推送，但前端不做任何处理，服务器就不会崩溃。
所以初步定位，前端有问题，但是我一直有疑问，就算前端有问题，也不可能让服务器挂掉，后端肯定也有内存泄露
经过几轮的讨论，我们最终把问题定位在SignalR上面，SignalR会造成内存泄露？？？很明显，单纯的SignalR肯定是不会造成内存泄露的，那问题出现哪里呢？
SignalR每300毫秒就推送一次，推送的如此频繁，前端逻辑处理会不会超过300毫秒。如果超过300毫秒，会有什么问题？
经过验证发现，当wafer作用到一半的时候，浏览器就开始卡顿，说明前端逻辑处理时间超过了推送时间，通过控制台打印，很明显证实了这一点：
wafer刚开始作业的前端逻辑解析时间：

wafer工作一段时间之后，前端解析时间：

那同样的代码，为什么解析的时间会越来越大，检测signalR推送的内容发现，之前有一个字符串随着时间的推移，字符串越来越大，前端解析这个字符串的时间也就越来越长
当前端解析signalR逻辑时间大于推送时间的时候，就会造成signalR消息队列的堵塞。
如果消息推送和处理时间存在冲突，可能会导致消息在客户端积压，这样浏览器解析的时间就会越来越慢就会卡顿，甚至崩溃。同时也会导致服务器产生大量的等待处理的消息队列，耗尽服务器资源，如处理器、内存和网络带宽。这可能会导致服务器性能下降，甚至可能导致服务器崩溃或瘫痪

至此就找到了问题了原因。完美解决！！！