用户队列管理：（在Utm主对象UserThreadMode中可以获得该实现）
com.dc.utm.manager.UserQueueManager 提供了用户队列的管理的接口，其中主要是：挂起当前用户队列 和 恢复队列。
（该管理类提供了很多的比较特殊的方法，例如放弃队列、清理队列任务等，建议谨慎使用！！！）
其中挂起用户xxx队列 和 恢复用户xxx队列可以被使用来做一个异步处理：
eg：用户当前请求需要调用一个外部处理，而这个外部处理的时间比较长。
处理方式1：同步方式：如果线程停在调用处等待的话，则当前线程会被挂起，如果有很多用户请求该操作就会导致很多线程在该处等待；最简单的方法是把用户请求线程池的线程数量调大，这样的话存在一个隐患就是当这个外部调用出现问题时（有可能这是一个其他公司提供的接口，接口的稳定性等不在你的把控范围之内），可能导致当前线程池的所有线程都卡在这里，导致服务处于假死状态，影响了所有用户的使用。
处理方式2：异步方式：当发送完外部处理的请求后把当前队列挂起（调用挂起方法），然后返回（utm将释放当前线程），而在此之后的请求将会被放置在队列中，但是不会被处理，因为当前队列的状态是被挂起的状态。然后等待外部处理返回并继续处理应该处理的信息，然后调用恢复队列，之后队列会继续处理该用户的后续请求。
（绿色线条为Utm线程池线程调用，红色为其他线程调用）
处理方式3：半异步方式：在该请求处理方法中调用其他的线程池处理该请求，然后把当前队列挂起（调用挂起方法）并返回（utm将释放当前线程），而在此之后的请求将会被放置在队列中，但是不会被处理，因为当前队列的状态是被挂起的状态。然后在其他线程池中的请求处理完后，然后调用恢复队列，之后队列会继续处理该用户的后续请求。
（绿色线条为Utm线程池线程调用，红色为其他线程调用）
在风险管控和性能把握的角度来说，处理方式2和3明显优于1，因为其都不会占用现在的用户线程池中的线程（因为他们都返回了调用，意味着当前线程执行完毕，而当用户队列出于挂起状态的时候将不会再调用线程池中的线程继续处理）；处理方式2 和 3的区别是3还是有其他的线程在等待，但是其并不会影响utm线程池的使用（如果utm线程池被阻塞则意味着无法及时的响应用户的请求），相对来说处理2更加干脆但程序上的编写和异常上的处理也将更加的复杂，可以根据实际情况决定采用哪一种模型处理。
用户异常处理：（在Utm主对象UserThreadMode中可以获得该实现）
com.dc.utm.manager. UserManager 提供了用户管理的一些功能。
其中包含处理用户异常的一个方法：deepCleanUser：
更详细的内容，可见实现代码中注释。
4563
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
