当我们想要轮询和服务端通信的时候，上面是一个典型的请求方法，通过interval操作符来实现轮询，然后subscribeOn里切换到io线程，看起来没有问题，功能也能运行，然后这里面还是有一个隐患存在的。
如图所示，我在map操作符里打印了当前的所在线程：
发现结果并不符合我们的预期，这根本不是io型的线程，而是 Schedulers.computation() 对应的线程；
而RxJava里的computation是固定线程数（CPU个数）的线程池，当我们的APP里有其他异步操作使用computation线程池导致核心线程全部被占用了，那网络请求的任务就发不出去了，就会出现网络请求迟迟没有回应甚至卡顿等问题，而且一旦出现此问题，很难定位。
可是，为什么呢？ 我们明明在后面进行了线程的切换啊？
原因：
其实只要查看一下interval的源码就可以发现：
nterval操作符的线程调度看起来是不受subscribeOn影响的，里面默认指定了computation线程池；
那我们就不能指定io线程池进行操作了吗 ？
当然不是，其实很简单
只要在初始化interval的时候指定所在线程为io线程就可以了，当然，后面的subscribOn也就没必要存在了。
如上修改之后，在通过日志发现，当前所在线程符合预期了。
