release_lonely的博客

2.应用服务器向微信提供的接口发送请求，该请求拼接上了该应用注册时的公众号的唯一标识（appid），请求成功后的回调函数（redirect_uri），返回类型（response_type，code类型），应用授权作用域（scope），重定向参数（state，非必须），#wechat_redirect等。6.后端获取access_token后拼接上自己的appid与返回的语言种类后在向微信服务器请求，成功后微信会返回请求对象的个人信息。微信登录需要先授权并且有一个可以被外界访问的服务器，我们来讲讲。

语句获取到连接，但是还需要将这个连接交给worker线程来处理读写请求，这就要求我们一定存在worker线程并且正在工作，但是工作状态的worker线程在没有任务进来的情况下会被多路选择器（selector）阻塞在select方法处，而我们又需要将连接sc注册到worker的selector上让它去监听这个连接上的事件，由于selector被阻塞我们无法完成注册，这就尬住了。但是引入多线程后线程间的执行顺利我们需要控制，比如当boss线程接收到一个请求后执行。

nio发送请求后不会进入阻塞，但是因为请求一版都是配合while(true)实现，所以nio会不断在用户层和系统层间切换查询结果，知道系统层将结果传给用户层，这样虽然不像bio一样一旦被阻塞只能等待当前事件完成才能执行别的事件，但频繁的在两个层级间切换开销大，性能不高。多路复用模式采用两者结合，在没有事件触发时会阻塞等待，当有事件触发后则会执行事件，这样不仅避免了bio在等待数据时的浪费效率，又避免了nio在等待事件时的不断切换带来的性能开销。因为java不具备读写的能力需要调用内核态的读写功能。

想必大家一定发现bio的明显的弊端了吧，随着接入的客户端越来越多服务器创建的线程数也就越多，在提供服务时在不同线程间的切换（需要保护当前现场，恢复下个线程运行的环境）也会越频繁，这会造成cpu利用的极大浪费，且这种模式的接入量存在明显的上限。但是需要thread去不断轮询clients，当clients非常大的时候循环的事件开销就会很大，并且对于客户链来说需要执行读写操作的时间和数量只占很小的一部分，所以对于轮询操作不仅耗时而且大部分操作是无效的。所以根本问题就在阻塞上，阻塞导致原线程无法提供服务。