问题背景
C#小白，由于本公司IM系统服务端（java）是本人独立开发的，加上现在所在项目需要对接IM系统，于是IM的客户端（C#实现）对接工作就交给我了。于是C#小白的我天真的以为只要调用C#端的SDK接口真搞定了。起初都还好，对接工作都很正常，没什么大问题。可是随着时间的不断流逝，终于在项目组小伙伴的不断使用中发现经常登不上IM系统，然而让我过去调试的时候又发现是正常的，让人很抓狂有木有！
直到他们再次重现BUG给我看的时候，我发现服务端日志中不断收到登录请求，而且他们程序关闭之后还是这样，小伙伴们百思不得其解，都怀疑我的服务端代码有问题。对服务端代码很熟悉的我自然不会认为服务端会有什么问题，因为登录只有收到客户端的UDP请求才会触发，而客户端不断发送登录请求这种情况也只有客户端自动重连机制了。而客户端正常退出时 根本不会触发自动重连机制，因为正常退出时会发出登出请求，并且会释放自动重连，心跳以及QoS等资源，那就只有异常退出时可能会出现这种问题了，如：任务管理器强制杀死程序、程序卡死、闪退等情况，他们在开发调试的时候也经常通过IDE直接关闭。于是我做了一个实验，在客户端登录成功后，反复n次正常登陆登出，没有任何问题；然后又尝试了异常退出，虽然没有立即登出IM系统（没发登出请求嘛），但也不会出现疯狂重连的情况，当然10s没有心跳服务器自然认为用户掉线了，一切正常；下面开始重头戏了，我改了客户端SDK的代码，在登陆成功后直接调用自动重连机制，然后任务管理器强制杀死程序，果不其然，BUG重现了。。。
问题探究
问题已经很明确了，非正常情况下的程序关闭并且自动重连程序在执行中的时候服务端会不断收到登录请求。到底是什么原因导致的呢？于是我不(忐)慌(忑)不忙(安)的去看了下客户端SDK中自动重连部分的代码，这里主要依靠timer定时器每隔2s发一次登录请求，直到登录成功为止。琢磨了一会儿也没发现有什么问题，慢慢的我开始猜测会不会是这timer有问题？于是把timer换成了Thread，通过Thread.sleep(2000)加是否重连成功的状态位来达到定时的效果，然后心怀期待的去测试，依然是在登陆成功后直接调用自动重连机制，然后任务管理器强制杀死程序，BUG消失了。一时兴奋的我多测试了几次，终于可以确定是timer的问题了，欣喜若狂的我心里不免开始了咒骂，哪有进程都杀死了，线程还在跑的道理嘛！！！
解决问题
C#中的timer定时器分为三种：基于服务器的计时器System.Timers.Timer、线程计时器System.Threading.Timer以及基于 Windows 的标准计时器System.Windows.Forms.Timer。其中第一种和第二种都是通过threadpool新开一个线程，因此效率较高；而第三种则是通过windows消息机制实现，和它所属的Form属于同一个线程，故效率较低。由于IM是不依赖于窗体的，属于后台独立线程，故排除第三种的使用可能。而IMSDK中使用的是第一种System.Timers.Timer而出现的问题，故我选择使用第二种线程计时器System.Threading.Timer来代替，经过大量测试后，完美解决问题，故记录一番。
至于System.Timers.Timer为什么会出现这种情况，在下学疏才浅，实在不知道为什么，希望知道的大神能点拨一二，不胜感激！