SocketRocket BAD_ACCESS 崩溃实例
在使用 SocketRocket 作为我们的 socket 服务的过程中，不时的会收到一两条 BAD_ACCESS 的崩溃。
崩溃的细节与 Github 上的两个 issues 相似：
SRProxyConnect Crash #587
Crashing at -[SRWebSocket stream:handleEvent:] (SRWebSocket.m:1405) #156
具体表现为 -[SRProxyConnect stream:handleEvent:] 或者 -[SRProxyConnect _configureProxy] 过程中出现 BAD_ACCESS 崩溃。
在调用栈上看不出什么，整个调用栈看起来比较正常。但细看 crash 行数，就会发现，都是在访问self（SRWebSocket、SRProxyConnect）的时候报的crash。
method执行过程中self被释放，基本可以肯定是线程问题。
以此为线索，结合 issue 156 的评论区，发现代码中有几个问题。
其一是Socket释放问题。由于平台设计，Socket的URL是与用户 session 相关的，每次用户 session 变化都会改变 socket 的 URL，而 SRWebSocket 的 URL 是在初始化的时候确定的，在 socket 生存期内是只读的。因此，我们采取的方案是在URL改变的时候断开之前的 socket，并重新初始化一个新的。断开连接代码如下：
[_webSocket close];
_webSocket.delegate = nil;
_webSocket = nil;
这样会导致socket断开连接的过程中 _webSocket 就由于未被持有被直接释放了，clean up 不到位。因此我们采用了 jtreanor 提到的措施使用一个 SRWebSocketCloser 来负责持有 socket 直到 clean up 结束。
但这样还不够，我们还有几个 crash 也是与 Socket 服务相关，其中一个 unrecognized selector 崩溃，调用栈在socket服务，但 crash 原因却是一个完全无关的类的 unrecognized，说明当前对象已经被释放并且被复写。
于是在 demo 中开了两条线程做循环，并且开启 Thread Sanitizer，压测多线程的 data race。
经过修复，压测跑到 Xcode 崩溃 app 都没崩┑(￣Д ￣)┍。
