Java常用网络类库与Socket编程_技术教程

Java Socket默认阻塞，易致线程膨胀；SocketChannel配合Selector实现非阻塞，需手动处理返回值。HttpClient重配置，OkHttp轻量异步。Netty是事件驱动框架，非简单NIO封装。WebMvc与WebFlux底层网络模型不同，不可仅靠返回类型切换。

Java原生Socket API的阻塞与非阻塞区别

Java的java.net.Socket默认是阻塞式IO，调用read()或write()时线程会挂起，直到数据就绪或写入完成。这在高并发场景下容易因线程数膨胀导致OOM或上下文切换开销过大。

非阻塞模式必须配合java.nio.channels.SocketChannel和Selector使用——它不等于“更快”，而是把控制权交还给应用层，由你决定何时轮询、是否超时、如何复用线程。

Socket适合简单工具类、调试客户端、低频通信（如配置同步）
SocketChannel适合长连接服务端（如IM网关、设备心跳）、需单线程管理数千连接的场景
注意：SocketChannel.configureBlocking(false)后，所有IO操作都必须检查返回值：read()可能返回-1（对端关闭）、0（暂无数据）、正数（实际读取字节数）

Apache HttpClient vs OkHttp：选型关键点

二者都是HTTP客户端库，但设计哲学不同：HttpClient偏重企业级可配置性（连接池、重试策略、NTLM认证），OkHttp更轻量、默认启用连接复用与GZIP，并内置Call/Callback异步模型。

常见误用：

用HttpClient发大量短连接却不配置PoolingHttpClientConnectionManager → 连接耗尽、TIME_WAIT堆积
在Android项目中硬塞HttpClient（已从SDK移除）→ 编译失败或运行时NoClassDefFoundError
用OkHttp的Call.enqueue()在主线程回调UI → Android 4.0+会抛NetworkOnMainThreadException

OkHttpClient client = new OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(30, TimeUnit.SECONDS)
    .build(); // 不要每次请求都new一个client！

Netty不是“高级Socket封装”，而是事件驱动网络编程框架

很多人以为Netty只是“更好用的NIO封装”，其实它抽象的是ChannelPipeline、EventLoopGroup、ByteBuf三层模型。直接拿SocketChannel写TCP粘包处理要自己维护缓冲区、判断边界；而Netty用LengthFieldBasedFrameDecoder一行配置就能解决。

典型踩坑：

在ChannelHandler的channelRead()里做耗时操作（如DB查询、文件IO）→ 阻塞整个EventLoop线程，影响同组其他连接
忘记调用ReferenceCountUtil.release(msg )释放ByteBuf → 内存泄漏，堆外内存持续增长
用SimpleChannelInboundHandler却没重写exceptionCaught() → 异常被吞掉，连接静默断开

Spring Boot WebMvc与WebFlux共存时的网络行为差异

同一个Spring Boot应用里，@RestController（基于Servlet容器，如Tomcat）走的是传统线程池模型；@RestController + @RequestMapping(produces = MediaType.TEXT_EVENT_STREAM_VALUE)或WebFlux则依赖Reactor Netty，底层用EpollEventLoopGroup（Linux）或KQueueEventLoopGroup（macOS）。

这意味着：