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异步模型。
常见误用：
立即学习“Java免费学习笔记（深入）”；
- 用
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）。
这意味着：
- HTTP/2支持只在WebFlux + Reactor Netty下开箱即用；WebMvc需额外配Tomcat 9+且启用ALPN
- WebMvc的
@Async方法仍受限于Servlet容器线程模型；WebFlux的Mono.delay()是纯事件调度，不占线程 - 日志中看到
reactor-http-epoll线程名，说明流量进了WebFlux栈；看到http-nio，说明走的是WebMvc
别指望把WebMvc接口改成return Mono.just(...)就自动变响应式——返回类型不改变底层执行模型。
