如何解决进程间通信
进程间通信都是基于RPC的，RPC这个技术的底层设计思想就是应用了我们的代理设计模式
Dubbo底层本质上也会做代理：Dobbu底层基于Spring的Aop适配了代理。
通讯，我们需要解决序列化，需要解决序列化过程的效率问题。
什么是Socket
Socket是一种基于TCP/IP协议网络编程接口也就是套接字，socket不感知应用层协议，应用程序可以通过他发送和接收数据，与网络中的其他应用程序进行通信，网络套接字是Ip和端口的组合。
为了满足不同的应用程序一般的通络系统，提供了三种不同类型的套接字：流式套接字，数据报套接字和原始套接字，不同的操作系统对于Socket的实现是不一样的。
网络通信程序如何辨识自己和对方？
三点：ip地址+端口号+通信协议
端口号对应应用程序，端口号位于传输层，有两种协议，一种是TCP协议，一种是UDP协议，这两种协议端口号是公用的，我们通过ip+端口号+通信协议，就可以唯一标识双方：
本机ip+本机端口+本机协议
远程ip+远程端口+远程协议
可以标识方双，双方一定是使用同样的协议就能进行通信。
多线程版网络编程的问题
1、线程创建是虚拟机与操作系统进行通讯属于创建开销很大
2、线程会占用很多大量内存，一个线程会占用1mb左右的内存
3、线程上下文切换一定是占用CPU浪费了大量CPU的资源
线程池版网络编程好处和问题
解决了线程了创建的开销和内存占用高的问题，不能无限制创建线程，CPU使用率较高的问题也得到了环节。但是来了一个新的问题：因为阻塞，造成了有限的线程资源的浪费。
案例说明：
客户端1阻塞了，比方说客户端1建立连接之后，需要输入点东西。导致后台线程一致空空置状态。这个问题当前环境是没有办法解决的。这个就会导致并发性变差，因为有大量新请求进入到阻塞队列当中。
本质上来讲，这种方式很好解决了多线程版的问题，基于线程池解决了大量创建线程的开销，合理的使用内存和CPU，但是也会出现因为客户端阻塞造成的后台线程资源浪费。
NIO网络通信中的非阻塞编程
NIO的网络通信中的特点在于，客户端不再使用流这种传统的IO方式进行，传统的流的这种形式都会基于InputStream或者OutPutStream来进行输入和输出。但是在NIO当中，是使用的是管道的这种形式。
每个客户端对应着一个管道，每一个请求发送给我们的服务器，我们NIO在网络编程当中，不仅仅保留了ServerSocket，还引入了一个非常重要的类型Selector(选择器)
作为selector来讲，能帮我们解决的问题是这样的，监控个客户端的channel这是一种主动式的监控，如果是客户端发短信进行通信的时候，是否能进行正常的通讯（1.正常的鉴别原因，没有阻塞。）监控过程当中有正常的读写，且无阻塞，就会给他分配线程。当其中某一个客户端channel阻塞了之后，会被selector监控到，就会把分配给他的后台线程解放出来，给到其他的channel，这跟传统的网络通通信有一个本质的区别，后台的线程当中可能同时给多个channel使用。这就是NIO版的网络通信，解决客户端阻塞导致后台资源闲置的方式。基于NIO网络通信技术，在客户端和后台服务体系中引入channel和Selector之后，后台线程的阻塞问题得到了解决。
说一说常用的几个Channel
文件操作:
FileChannel读写文件中的数据。
网络操作:
SocketChannel：通过TCP读写网络中的数据
ServerSocketChannel：监听新进来的TCP链接，对每一个新进来的TCP链接创建一个SocketChannel
DatagramChannel：通过UDP读取网络中的数据
