即时强制下线这个功能一般是用在当用户使用设备A登录后，又用设备B登录这个用户的账号，设备A上的客户端强制当前用户下线。即不能在多台设备上同时登录一个账号。
逻辑图如下: 
逻辑图解释：核心(用户只要进行登录操作或者更改密码操作都更改这个用户的Token)当用户使用设备进行登录时，登录成功后更改用户的Token，并将这个Token返回给客户端，客户端将这个Token存储到本地，在这个用户的以后的访问的时候都带上这个Token，服务器端将这个客户端带来的Token与服务器的Token进行比较，如果一致返回正确数据信息，不一致返回强制下线的信息，客户端根据返回的信息进行不同的处理。
这个逻辑怎么实现的呢？
假设用户在设备A上进行了登录操作，更改了服务器的Token，那么在没有下一次登录操作的时候服务器上都是这个Token，用户的后续请求都能正确响应，就算用户登出了这个账号，再次进行登录的时候又触发了更改服务器Token和返回Token的操作，也没妨碍。
但当用户在设备A上进行登录后，一直处于登录状态，再在设备B上进行登录，触发了服务器Token的改变，设备A上再使用存储的Token进行访问数据时就触发了Token不一致，设备A将收到服务器发出的强制下线信息，退回到登录界面。
当用户进行更改密码操作的时候，导致了服务器Token的改变，用户再用设备上存储的Token进行访问时也触发了Token不一致，收到服务器发出的强制下线信息，退回到登录界面。
这就是我对实现即时强制下线(其实并没有实现真正意义上的即时，只是在用户请求下一次数据时才触发)的逻辑想法，不知道有没有什么疏漏，有不足之处请告知。