socket连接---多线程 线程池---TCP/IP半包、粘包、分包
PS： socket是TCP/IP的封装，URL类（java中）是对Socket 的封装。
一 ServerSocket工作原理：
客户端socket请求连接Serversocket的请求连接，按照请求顺序进入客户端连接请求队列(队列的容量是由操作系统完成的)，ServerSocket的构造函数中的backlog就是用来指定请求队列的长度。 这个值会失效的三种情况：大于操作系统默认值|小于等于0|没有设置。 （见下面）
serversocket中的accept方法，会从客户端连接请求队列（先进先出）中取出一个请求连接的请求，生成一个用于通信的socket。只有当serversocket的accept方法成功返回时，才表明客户端与服务端建立了连接。
socket连接是Java中进行通信的基本方式，也是效率最高的方式，虽然他有http等让是进行http请求，但是如果是进行tcp、下载等通信，还是使用socket更好。Java中封装了非常完美的socket机制，使用也非常简单。主要包括socket和serversocket。
socket的使用非常简单，主要包括的构造方法有：socket(),socket(string host,string port),socket(Inetaddress address,int port)等，非常明白了，通过传入host和port进行socket的请求，当在创建相应的套接字实例的时候，会自动去对相应的ip和port进行连接，只有当连接成功，才表示相应的套接字建立成功，才可以进行相应的I/O操作。通过getOutputStream和getInputStream获取相应的输入输出流，进行相应的I/O操作，但是有一个是比较特别的，getChannel用来获取SocketChannel，他之所以特别是因为他属于java.nio.channels下面的类，其继承于java.nio.channels.SelectableChannel，就是说在进行nio非阻塞式的请求连接时，他非常有用，具体参见http://www.cnblogs.com/likwo/archive/2010/06/29/1767814.html。可能有些人会问，对于可以通过设置服务器连接的timeout来防止过多的阻塞，但是如果对于超过timeout，socket一般是抛出超时异常，这样就算对异常进行了处理，也将会从新建立socket连接，浪费消费 重建的资源。例如QQ聊天，当你打开一个聊天面板，很久不说话的时候，并不会自动为你断开socket连接，而是一直处于阻塞状态，直到你发送了新的信息，再进行处理，因此nio的阻塞方式会更好些。
对于serversocket也比较简单，常用的只有四个构造函数：
l ServerSocket()throws IOException
l ServerSocket(int port) throws IOException
l ServerSocket(int port, int backlog) throws IOException
l ServerSocket(int port, int backlog, InetAddress bindAddr) throws IOException
分别对这几个构造进行简单的解释：
第一个无参构造，只是创建一个serversocket实例，但是不进行任何端口的监听，你还必须通过bind方法进行端口的绑定，好处就是在绑定之前可以进行相应属性的设置，例如so_reuseaddress等；
第二个构造函数需要一个端口(1024-65535)，一般不使用0-1023之间的，这个属于系统占用的预留端口，但是如果你传入的端口号为0，则会默认使用匿名端口，就是系统随机分配一个端口，进行暂时通信，这个匿名方式，一般情况下不使用；
第三个构造函数需要一个端口，和一个backlog(监听对列大小)，serversocket进行某端口的监听，当有多个连接请求是，每个请求默认都会放入一个请求队列里，如果你没有设置这个值，则默认为操作系统的值，根据不同的系统有所不同，例如40等，有几种情况，这个值将会失效：大于操作系统默认值|小于等于0|没有设置。如果设置了，而没有及时对队列进行处理，则会报ConnectException异常；
第四个构造函数除了具有端口、队列大小外，还具有一个参数是ip地址，就是进行相应ip地址的绑定。当然，这个进行的是服务器ip地址的绑定，不会限制客户端的ip访问。当一台服务器存在多个网卡的时候，就需要通过这个参数来设置客户端访问的ip。
服务器socket的关闭，通过使用close进行关闭，使用isclosed进行判断，还可以进行端口的绑定判断。
对于服务器close方法，需要有一点进行说明：调用close方法之后，操作系统并不会立即进行端口的释放，依旧会对旧端口占用一段时间，以防止客户端发送的数据有延迟现象。因此有时候，就算你进行了close方法的调用，进行了端口的释放，但是如果你立即进行同一个端口的连接时，依旧会包端口占用异常，这个是可以理解的。
serversocket通过使用accept方法进行客户端请求的处理，每当请求队列里有客户端请求时，serversocket就会从队列顶端取一个socket请求进行处理，生成一个socket来负责与客户端通信。如果一个时间只能处理一个socket，当有多个客户端请求时，则必须要排队处理，等待所有前面的socket处理完，这是个极其痛苦，并且不合理的过程。因此，引入了线程的概念。
二 socket与多线程
为了实现客户端请求的快速相应和快速处理，据是高并发，则必须使用多线程机制。主题思想是：serversocket通过accept建立一个socket，然后起一个线程，把这个socket扔给新建的线程进行处理，而serversocket所在的主线程，则继续去监听端口，以此实现多线程通信。一般有三种方式：
1、每一个socket请求就建立一个线程。这个是最简单的方式，大致代码如下：
- public void service() {
- while (true) {
- Socket socket=null;
- try {
- socket = serverSocket.accept(); //接收客户连接
- Thread workThread=new Thread(new Handler(socket)); //创建一个工作线程
- workThread.start(); //启动工作线程
- }catch (IOException e) {
- e.printStackTrace();
- }
- }
- }
上面的方式非常简单，能够处理基本的多线程问题，当数据量不大时，应该没有什么问题，但是如果数据量过大时，就会出现严重的性能，甚至是宕机问题。其缺点主要有如下几个：
a:每个socket请求，建立一个连接，当每个都是进行简短的通信时，则异常的耗费系统建立、销毁线程资源。
b:如果建立线程太多，每个线程都会占用一定的系统内存，这样将导致内存溢出。
c:频繁地对线程进行建立 销毁，会导致操作系统进行频繁的cpu切换线程切换，这样也会非常耗费系统资源。
2、自己实现线程池。
自己写线程池，能够对线程池的工作原理以及工作情况，更加的了解和控制，但是由于线程池必然涉及到多线程问题，因此为了防止出现死锁、线程泄漏、并发错误、任务过载等问题，需要性能非常好的机制，一般不推荐个人现实。如果非要实现，可以通过使用linkedlist
3、使用jdk自带的线程池。jar包是：java.util.concurrent
这个jar包都是一些并发编程会经常使用到的工具类，主要有阻塞队列，原子操作的map以及线程池等。其基本包括Executor、ExecutorService接口和Executors类，两个接口定义了执行线程的方法，而Executors则定义了管理线程池的方法，主要可以创建的常用线程池有：
newSingleThreadScheduledExecutor() 创建一个可以延迟执行和定时执行的单线程线程池
newSingleThreadExecutor() 创建一个运行单线程的线程池 new LinkedBlockingQueue
newScheduledThreadPool(int corePoolSize) 创建一个可以延迟执行和定时执行的线程池，设定线程数，常用来代替Timer（定时器)
newFixedThreadPool(int nThreads) 创建一个固定线程数的线程池 new LinkedBlockingQueue
newCachedThreadPool() 创建一个带有缓冲区的线程池 new SynchronousQueue
然后通过生成的线程池的execute方法进行线程的执行，具体可以百度下哈哈
使用线程池有以下几点风险：
1、死锁。任何多线程都不可避免的问题。但是对于线程池可能会存在另一种死锁：就是线程池中的线程都在等待一个资源，而这个资源需要执行A后得到，而由于线程池没有可用的线程，导致A无法执行，故而也会发生死锁。
2、系统资源不足。多线程必定需要大量的内存资源，可能出现内存泄漏问题。
3、并发错误。
4、线程泄漏。就是所有的线程池中的线程都在等待输入资源，或者都抛出了异常而没有捕获，则会导致线程池中所有的线程假死。
5、线程过载。运行线程过多，导致过载，这个可以通过设置线程池的大小来进行一定成功的避免。
至于如何避免，主要是要在使用多线程时要小心，同时不要使用destroy despause 等操作，尽量使用sleep notify wait等操作，在这里不详细说明了。
二 补充：JDK1.5中线程池的简单使用(java.util.concurrent.ThreadPoolExecutor)
在多线程大师Doug Lea的贡献下，在JDK1.5中加入了许多对并发特性的支持，例如：线程池。这里介绍的就是1.5种的线程池的简单使用方法。
一、简介
线程池类为 java.util.concurrent.ThreadPoolExecutor，常用构造方法为：
- ThreadPoolExecutor(int corePoolSize,
- int maximumPoolSize,
- long keepAliveTime, TimeUnit unit,
- BlockingQueue
workQueue, - RejectedExecutionHandler handler)
- corePoolSize
线程池维护线程的最少数量 - maximumPoolSiz
线程池维护线程的最大数量 - keepAliveTime
线程池维护线程所允许的空闲时间 - unit
线程池维护线程所允许的空闲时间的单位 - workQueue
线程池所使用的缓冲队列 - handler
线程池对拒绝任务的处理策略
一个任务通过 execute(Runnable)方法被添加到线程池，任务就是一个 Runnable类型的对象，任务的执行方法就是 Runnable类型对象的run()方法。
当一个任务通过execute(Runnable)方法欲添加到线程池时：
- 如果此时线程池中的数量小于corePoolSize，即使线程池中的线程都处于空闲状态，也要创建新的线程来处理被添加的任务。
- 如果此时线程池中的数量等于 corePoolSize，但是缓冲队列 workQueue未满，那么任务被放入缓冲队列。
- 如果此时线程池中的数量大于corePoolSize，缓冲队列workQueue满，并且线程池中的数量小于maximumPoolSize，建新的线程来处理被添加的任务。
- 如果此时线程池中的数量大于corePoolSize，缓冲队列workQueue满，并且线程池中的数量等于maximumPoolSize，那么通过 handler所指定的策略来处理此任务。
也就是：处理任务的优先级为：
核心线程corePoolSize、任务队列workQueue、最大线程maximumPoolSize，如果三者都满了，使用handler处理被拒绝的任务。
当线程池中的线程数量大于 corePoolSize时，如果某线程空闲时间超过keepAliveTime，线程将被终止。这样，线程池可以动态的调整池中的线程数。
unit可选的参数为java.util.concurrent.TimeUnit中的几个静态属性：
NANOSECONDS、MICROSECONDS、MILLISECONDS、SECONDS。
workQueue我常用的是：java.util.concurrent.ArrayBlockingQueue
handler有四个选择：
- ThreadPoolExecutor.AbortPolicy()
抛出java.util.concurrent.RejectedExecutionException异常 - ThreadPoolExecutor.CallerRunsPolicy()
由调用者执行这个任务 - ThreadPoolExecutor.DiscardOldestPolicy()
抛弃旧的任务 - ThreadPoolExecutor.DiscardPolicy()
抛弃当前的任务
二、一般用法举例
- package cn.simplelife.exercise;
- import java.util.concurrent.ArrayBlockingQueue;
- import java.util.concurrent.ThreadPoolExecutor;
- import java.util.concurrent.TimeUnit;
- public class TestThreadPool {
- private static int produceTaskSleepTime = 2;
- public static void main(String[] args) {
- //构造一个线程池
- ThreadPoolExecutor producerPool = new ThreadPoolExecutor(2, 4, 0, TimeUnit.SECONDS, new ArrayBlockingQueue(3), new ThreadPoolExecutor.DiscardOldestPolicy());
- //每隔produceTaskSleepTime的时间向线程池派送一个任务。
- int i=1;
- while(true){
- try {
- Thread.sleep(produceTaskSleepTime);
- String task = "task@ " + i;
- System.out.println("put " + task);
- producerPool.execute(new ThreadPoolTask(task));
- i++;
- } catch (Exception e) {
- e.printStackTrace();
- }
- }
- }
- }
- package cn.simplelife.exercise;
- import java.io.Serializable;
- /**
- * 线程池执行的任务
- * @author hdpan
- */
- public class ThreadPoolTask implements Runnable,Serializable{
- //JDK1.5中，每个实现Serializable接口的类都推荐声明这样的一个ID
- private static final long serialVersionUID = 0;
- private static int consumeTaskSleepTime = 2000;
- private Object threadPoolTaskData;
- ThreadPoolTask(Object tasks){
- this.threadPoolTaskData = tasks;
- }
- //每个任务的执行过程，现在是什么都没做，除了print和sleep，:)
- public void run(){
- System.out.println("start .."+threadPoolTaskData);
- try {
- //便于观察现象，等待一段时间
- Thread.sleep(consumeTaskSleepTime);
- } catch (Exception e) {
- e.printStackTrace();
- }
- threadPoolTaskData = null;
- }
- }
对这两段程序的说明：
- 在这段程序中，一个任务就是一个Runnable类型的对象，也就是一个ThreadPoolTask类型的对象。
- 一般来说任务除了处理方式外，还需要处理的数据，处理的数据通过构造方法传给任务。
- 在这段程序中，main()方法相当于一个残忍的领导，他派发出许多任务，丢给一个叫 threadPool的任劳任怨的小组来做。
- 这个小组里面队员至少有两个，如果他们两个忙不过来， 任务就被放到任务列表里面。
- 如果积压的任务过多，多到任务列表都装不下(超过3个)的时候，就雇佣新的队员来帮忙。但是基于成本的考虑，不能雇佣太多的队员， 至多只能雇佣 4个。
- 如果四个队员都在忙时，再有新的任务， 这个小组就处理不了了，任务就会被通过一种策略来处理，我们的处理方式是不停的派发， 直到接受这个任务为止(更残忍！呵呵)。
- 因为队员工作是需要成本的，如果工作很闲，闲到 3SECONDS都没有新的任务了，那么有的队员就会被解雇了，但是，为了小组的正常运转，即使工作再闲，小组的队员也不能少于两个。
- 通过调整 produceTaskSleepTime和 consumeTaskSleepTime的大小来实现对派发任务和处理任务的速度的控制， 改变这两个值就可以观察不同速率下程序的工作情况。
- 通过调整4中所指的数据，再加上调整任务丢弃策略， 换上其他三种策略，就可以看出不同策略下的不同处理方式。
- 对于其他的使用方法，参看jdk的帮助，很容易理解和使用。
三TCP/IP，http，socket，长连接，短连接
TCP/IP是个协议组，可分为三个层次：网络层、传输层和应用层。
在网络层有: IP协议、ICMP协议、ARP协议、RARP协议和BOOTP协议。在传输层中有:TCP协议与UDP协议。
在应用层有: TCP包括FTP、HTTP、TELNET、SMTP等协议
UDP包括DNS(域名系统协议)、SNMP（简单网络管理协议）、TFTP（小型文件传输协议/简单文件传输协议）等协议
发送接收方式
1、异步报文发送和接收是分开的，相互独立的，互不影响。这种方式又分两种情况：
(1)异步双工：接收和发送在同一个程序中，由两个不同的子进程分别负责发送和接收
(2)异步单工：接收和发送是用两个不同的程序来完成。
2、同步
报文发送和接收是同步进行，既报文发送后等待接收返回报文。 同步方式一般需要考虑超时问题，即报文发出去后不能无限等待，需要设定超时时间，超过该时间发送方不再等待读返回报文，直接通知超时返回。
Socket是什么
Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。
Socket 通信示例
主机 A 的应用程序要能和主机 B 的应用程序通信，必须通过 Socket 建立连接，而建立 Socket 连接必须需要底层 TCP/IP 协议来建立 TCP 连接。建立 TCP 连接需要底层 IP 协议来寻址网络中的主机。我们知道网络层使用的 IP 协议可以帮助我们根据 IP 地址来找到目标主机，但是一台主机上可能运行着多个应用程序，如何才能与指定的应用程序通信就要通过 TCP 或 UPD 的地址也就是端口号来指定。这样就可以通过一个 Socket 实例唯一代表一个主机上的一个应用程序的通信链路了。
四socket的半包，粘包与分包的问题
首先看两个概念： 短连接--长连接
短连接：
连接->传输数据->关闭连接HTTP是无状态的，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。
也可以这样说：短连接是指SOCKET连接后发送后接收完数据后马上断开连接。
长连接：
连接->传输数据->保持连接 -> 传输数据-> 。。。 ->关闭连接。长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差。
http的长连接
HTTP也可以建立长连接的，使用Connection:keep-alive，HTTP 1.1默认进行持久连接（长连接）。HTTP1.1和HTTP1.0相比较而言，最大的区别就是增加了持久连接支持(貌似最新的 http1.0 可以显示的指定 keep-alive),但还是无状态的，或者说是不可以信任的。之所以出现粘包和半包现象,是因为TCP当中,只有流的概念,没有包的概念.
在长连接中一般是没有条件能够判断读写什么时候结束，所以必须要加长度报文头。读函数先是读取报文头的长度，再根据这个长度去读相应长度的报文。
什么时候用长连接，短连接？
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。
总之，长连接和短连接的选择要视情况而定。
半包
指接受方没有接受到一个完整的包，只接受了部分，这种情况主要是由于TCP为提高传输效率，将一个包分配的足够大，导致接受方并不能一次接受完。（ 在长连接和短连接中都会出现）。粘包与分包
指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。出现粘包现象的原因是多方面的，它既可能由发送方造成，也可能由接收方造成。发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。分包是指在出现粘包的时候我们的接收方要进行分包处理。（在长连接中都会出现）什么时候需要考虑半包的情况?
从备注中我们了解到Socket内部默认的收发缓冲区大小大概是8K，但是我们在实际中往往需要考虑效率问题，重新配置了这个值，来达到系统的最佳状态。一个实际中的例子：用mina作为服务器端，使用的缓存大小为10k，这里使用的是短连接，所有不用考虑粘包的问题。
问题描述：在并发量比较大的情况下，就会出现一次接受并不能完整的获取所有的数据。
处理方式：
1.通过包头+包长+包体的协议形式，当服务器端获取到指定的包长时才说明获取完整。
2.指定包的结束标识，这样当我们获取到指定的标识时，说明包获取完整。
什么时候需要考虑粘包的情况?
1.当时短连接的情况下，不用考虑粘包的情况
2.如果发送数据无结构，如文件传输，这样发送方只管发送，接收方只管接收存储就ok，也不用考虑粘包
3.如果双方建立连接，需要在连接后一段时间内发送不同结构数据
处理方式：
接收方创建一预处理线程，对接收到的数据包进行预处理，将粘连的包分开
注：粘包情况有两种，一种是粘在一起的包都是完整的数据包，另一种情况是粘在一起的包有不完整的包
备注:
一个包没有固定长度，以太网限制在46－1500字节，1500就是以太网的MTU，超过这个量，TCP会为IP数据报设置偏移量进行分片传输，现在一般可允许应用层设置8k（NTFS系）的缓冲区，8k的数据由底层分片，而应用看来只是一次发送。windows的缓冲区经验值是4k,Socket本身分为两种，流(TCP)和数据报(UDP)，你的问题针对这两种不同使用而结论不一样。甚至还和你是用阻塞、还是非阻塞Socket来编程有关。
1、通信长度，这个是你自己决定的，没有系统强迫你要发多大的包，实际应该根据需求和网络状况来决定。对于TCP，这个长度可以大点，但要知道，Socket内部默认的收发缓冲区大小大概是8K，你可以用SetSockOpt来改变。但对于UDP，就不要太大，一般在1024至10K。注意一点，你无论发多大的包，IP层和链路层都会把你的包进行分片发送，一般局域网就是1500左右，广域网就只有几十字节。分片后的包将经过不同的路由到达接收方，对于UDP而言，要是其中一个分片丢失，那么接收方的IP层将把整个发送包丢弃，这就形成丢包。显然，要是一个UDP发包佷大，它被分片后，链路层丢失分片的几率就佷大，你这个UDP包，就佷容易丢失，但是太小又影响效率。最好可以配置这个值，以根据不同的环境来调整到最佳状态。
send()函数返回了实际发送的长度，在网络不断的情况下，它绝不会返回(发送失败的)错误，最多就是返回0。对于TCP你可以字节写一个循环发送。当send函数返回SOCKET_ERROR时，才标志着有错误。但对于UDP，你不要写循环发送，否则将给你的接收带来极大的麻烦。所以UDP需要用SetSockOpt来改变Socket内部Buffer的大小，以能容纳你的发包。明确一点，TCP作为流，发包是不会整包到达的，而是源源不断的到，那接收方就必须组包。而UDP作为消息或数据报，它一定是整包到达接收方。
2、关于接收，一般的发包都有包边界，首要的就是你这个包的长度要让接收方知道，于是就有个包头信息，对于TCP，接收方先收这个包头信息，然后再收包数据。一次收齐整个包也可以，可要对结果是否收齐进行验证。这也就完成了组包过程。UDP，那你只能整包接收了。要是你提供的接收Buffer过小，TCP将返回实际接收的长度，余下的还可以收，而UDP不同的是，余下的数据被丢弃并返回WSAEMSGSIZE错误。注意TCP，要是你提供的Buffer佷大，那么可能收到的就是多个发包，你必须分离它们，还有就是当Buffer太小，而一次收不完Socket内部的数据，那么Socket接收事件(OnReceive)，可能不会再触发，使用事件方式进行接收时，密切注意这点。这些特性就是体现了流和数据包的区别。参考：http://www.cnblogs.com/canghaitianyuan/archive/2012/11/16/2772987.html
http://my.oschina.net/ksfzhaohui/blog/95451
《 java并发编程实践》
《java网络编程精解》
http://dalezhu.javaeye.com/blog/186895