gen_server的同步调用内部实现机制及From的前世今生

1、同步调用

 首先客户端进程通过call向gen_server发起同步调用，客户端进程会monitor向gen_server进程，返回一个监控句柄Mref，同时向gen_server进程发送｛Label，｛self（），Mref｝，Request｝后，客户端进程执行receive便进入阻塞状态，等待对应消息的到来。gen_server进程收到客户端发来的消息对其进行解析，解析出｛self（），Mref｝=From，即From是由客户端进程和客户端进程对gen_server的monitor句柄组成的一个元组，是客户端进程将自己的进程id发送给gen_server，gen_server解析出来后传给实现gen_server行为模式的同步回调接口，这就是From的前世今生，回调部分接口是在gen_server进程内部执行，通用部分接口是在客户端进程中执行。

      客户端进程一直在侦听消息的到来，如果收到了同步调用的返回值，客户端进程是这样做的，首先执行demonitor解除与gen_server的监控关系，进而将结果返回，客户端进程从receive的阻塞状态跳出来，对外表现为同步调用返回；如果收到gen_server进程发来的｛‘DOWN‘，Mref，_，_，Reason｝消息，客户端进程马上exit；如果timeout时间后依旧没有没有收到结果，便自动demonitor后，退出。

        总结：1、erlang底层之所以让客户端进程单向monitor目标gen_server进程，就是想在同步调用过程，让客户端与gen_server进程有个“握手-分手”的过程，一旦gen_server进程挂了，客户端进程能够收到DOWN消息，进而客户端进程退出;

                  2、当进程A与进程B既有link关系，又有A到B的monitor时，一旦B进程挂了，exit退出信号会优先‘DOWN’发给进程A。