1.ServerSocket

把连接到服务器的客户端进行统一处理.

1.serverSocket.accept

——》返回类型：Socket

如果客户端和服务器建立好了连接，服务器把内核建立好的连接拿到应用程序中。

如果没有建立好连接，accept阻塞。

注意：对端的IP与端口号信息都在accept返回的Socket对象中保存。

2.Socket

针对一个客户端，提供具体的服务.

1.socket.getInetAddress

拿到IP。

打印Ip.

不toString转为字符串也可以，%s会自动调用对象的toString（）。

2.socket.getPort

拿到端口号

3.socket.getInputStream

——》返回类型：InputStream

拿到socket对象内置的流对象。

read就是对socket读

4.socket.getOutputStream

——》返回类型：outputStream

write就是对socket写

3.TCP服务器

1.TcEchoServer

先连接，再通信。先连接指的是先接受客户端的连接。

客户端new Socket对象，就会触发TCP建立连接的流程，服务器不做任何处理，就能配合客户端把连接处理完。具体的连接流程是在操作系统内核实现的，服务器把内核建立好的连接拿到应用程序中。

每次服务器收到一个客户端连接，都通过ServerSocket进行accept。

1.长连接与短连接

TCP一次连接中，分为长连接与短链接。

长连接：一次连接，有多次请求

短连接：一次连接，只有一次请求

2.TCP是面向字节流的：

解析请求

方法一：

方法2：

把响应返回给客户端

或者：

3.bug1：缓冲区（buffer）

缓冲区本质是一段内存空间。

进行IO操作中，操作硬盘、网卡、打印机等，都属于低效操作（与内存相比）。

所以要尽可能减少访问这些慢速设备的次数。所以把要写入IO设备的数据，先放到缓冲区，等缓冲区满后统一写入到IO设备里。

但这种写法是有bug的：PrintWrter类内置了缓冲区，如果缓冲区没满，那就不会发送请求！服务器一直阻塞！

4.flush冲刷应用程序的缓冲区

即使缓冲区没满，也能真正写入。

5.bug2：关闭服务器accept返回的socket

服务器每与一个客户端建立连接，就会new一个Socket对象。socket本质是一个文件，且文件描述符表有上限，如果达到上限，程序就会崩溃。这是一个隐藏的bug，看起来不影响程序的运行，但隐藏着很大的隐患。

关闭：每new的一个socket的生命周期跟随一次连接，在连接结束后close

2.TcEchoClient

bug：一个服务器不能与多个客户端同时连接，需等前一个客户端结束连接后一个才能连接到服务器

因为服务器accept一个连接后，进入processConnection，只要这个客户端没有结束，服务器就一直在processConnection方法里循环，只有这个客户端结束连接后，服务器才能accept下一个客户端的连接。

解决方法：多线程

1.lambda表达式

this可省略

2.匿名内部类

lambda表达式内的this指的是：外部类的实例对象。lambda里的this和外层start方法里的this是同一个。this可省略。

匿名内部类内的this指的是：当前new的Runnable的实例对象。Runnable里没有processionConnection方法，不能直接写this.processConnection()。

要在匿名内部类里访问外部类的实例方法：外部类名.this.方法名（）

如果线程的数量过多，就可使用线程池：

4.IO多路复用处理海量长连接造成的线程瓶颈

一连接一线程模型的问题：

当大量用户同一时刻在线进行游戏、直播等这种持续时间很长的业务，会给服务器带来明显缺陷：

1.CPU核心数量有限。当线程数量过多（几千）时，操作系统频繁在线程之间切换，线程调度开销急剧变大，线程排队等待CPU的时间变长，响应变慢。

2.每个线程本身也要占用内存资源，海量线程会消耗大量内存。

5.

客户端在把请求发送给服务器时，结尾有一个“\n”

服务器在读取请求时，用的是next（），next遇到空白符就停止:

所以这两个是匹配的。

如果把客户端的改为：

那么服务器在读取请求时一直读不到结束，就会一直阻塞：

客户端也收不到响应一直阻塞。