1. 这不是教科书是我在高并发网关项目里踩出来的IO认知地图你打开IDEA写完一个new Socket()调用read()卡住三秒——这三秒里线程在哪CPU在忙什么操作系统干了啥内存页有没有换出这些不是面试八股文而是我去年重构公司支付网关时连续两周睡不着觉反复验证的问题。标题里写的“网络通信和IO”表面看是Java基础课实则是一张横跨用户态、内核态、硬件中断、内存管理的立体作战图。今天这篇只讲一件事所有IO操作的本质都是在和操作系统谈判资源使用权。你写的每一行FileInputStream.read()或SocketChannel.read()背后都站着Linux内核调度器、页表管理器、DMA控制器三个大佬。所谓BIO/NIO区别根本不是“要不要加个while循环”这种表层差异而是你主动把谈判权交出去BIO还是自己攥着谈判筹码去轮询NIO。文件描述符它根本不是“文件编号”而是内核给你发的一张带权限的门禁卡卡面印着fd3背面写着“可读/可写/超时时间500ms”。网络通信不过是把这张卡插进网卡驱动的读卡器让数据包顺着PCIe总线冲进内存。我见过太多人死磕ByteBuffer.allocateDirect()的堆外内存却从没查过/proc/sys/net/core/rmem_max这个内核参数——结果压测时连接数刚到2000java.io.IOException: Connection reset by peer就满屏飘红。这篇文章不讲API怎么用只拆解你敲下read()那一刻从JVM字节码到网卡LED灯闪烁的完整链路。适合正在写Netty中间件、调试Tomcat线程池、或者被CLOSE_WAIT状态搞崩溃的后端工程师。如果你还停留在“BIO是同步阻塞NIO是非阻塞”这种PPT式理解现在就是撕掉幻觉的最佳时机。2. 内容整体设计与思路拆解为什么必须从Linux内核视角切入2.1 拒绝Java API层幻觉所有IO最终都归于系统调用很多人学IO时陷入一个致命误区把java.io包当成独立世界。实际上FileInputStream.read()最终调用的是read(2)系统调用Socket.getInputStream().read()走的是recvfrom(2)而java.nio里的channel.read(buffer)底层仍是read(2)或recvfrom(2)。我曾用strace -e traceread,write,recvfrom,sendto跟踪一个简单HTTP服务发现每处理1个请求平均触发17次系统调用——其中12次是IO相关。这意味着Java IO模型的性能瓶颈90%不在JVM而在内核态与用户态的上下文切换开销。所以本文设计逻辑是倒推先锁定Linux内核中IO的核心机制文件描述符表、socket缓冲区、epoll_wait再反向映射Java各IO模型如何与之交互。比如“阻塞IO(BIO)”的“阻塞”本质是进程在__wait_event_interruptible()函数里挂起等待socket接收缓冲区有数据而“非阻塞IO(NIO)”的“非阻塞”是调用read(2)时传入O_NONBLOCK标志内核直接返回EAGAIN错误而非挂起进程。这种设计避免了空谈概念每个术语都有对应的内核函数、系统调用参数、内存地址空间作为锚点。2.2 文件IO与网络IO的统一性它们共享同一套内核基础设施标题里问“文件IO和网络IO的区别”但Linux内核根本不区分这两者。open(/tmp/data.txt, O_RDONLY)和socket(AF_INET, SOCK_STREAM, 0)返回的都是文件描述符fd都存放在进程的files_struct结构体中。我用ls -l /proc/$(pidof java)/fd/查看过运行中的Netty服务你会发现fd3可能是日志文件fd4是监听端口fd5是客户端连接——它们在内核眼里全是struct file对象。区别仅在于file-f_op指向的操作函数集文件IO走ext4_file_operations网络IO走inet_stream_ops。但底层内存管理完全一致都使用page cache缓存数据都通过copy_to_user()将内核数据拷贝到用户空间。正因如此sendfile(2)系统调用才能实现零拷贝——它让内核直接把磁盘page cache的数据通过DMA引擎送入网卡全程不经过用户空间。这种统一性解释了为什么Java NIO能用同一个Selector管理文件通道和网络通道虽然实际很少这么做。我们的内容设计刻意打破“文件IO/网络IO”的割裂认知用/proc/[pid]/maps内存映射图展示两者共享的虚拟内存布局让读者看清mmap()映射的文件和ByteBuffer.allocateDirect()分配的堆外内存在物理页层面如何共用同一片RAM。2.3 BIO/NIO的本质分水岭谁控制阻塞决策权这是全篇最核心的设计支点。BIO与NIO的根本差异不在于是否用ByteBuffer而在于阻塞行为的决策主体。BIO模式下阻塞决策权完全交给内核当应用调用read()内核判断缓冲区无数据立即把进程状态设为TASK_INTERRUPTIBLE并加入等待队列CPU切走执行其他进程。NIO模式下应用通过configureBlocking(false)把决策权抢回来内核不再自动挂起进程而是立刻返回-1并置errnoEAGAIN由应用自己决定是重试、休眠还是处理其他任务。我在线上环境做过对比实验用BIO处理1000个长连接需要1000个线程top显示%CPU稳定在98%但%wa(IO等待)高达45%换成NIO单线程SelectorCPU使用率降到12%%wa趋近于0。因为NIO把“等待”从内核态转移到了用户态——Selector.select()在内核epoll_wait()中阻塞但整个过程只占用1个线程。这种设计思路决定了我们不会罗列API用法而是聚焦epoll_ctl()如何注册事件、SelectorImpl如何封装epoll、sun.nio.ch.EPollArrayWrapper如何管理就绪事件数组等真实代码路径。2.4 JAVA生态的特殊性JVM如何成为IO性能的放大器或绊脚石标题明确指向JAVA这就必须直面JVM的双刃剑效应。一方面java.nio通过DirectByteBuffer绕过JVM堆内存让ByteBuffer直接映射到物理内存避免了byte[]在GC时的复制开销另一方面Selector的select()方法在Linux上实际调用epoll_wait()但JVM为了跨平台兼容在Windows上却用select(2)模拟导致同样的代码在Windows服务器上性能断崖式下跌。我曾为金融客户做跨平台部署同样配置的Netty服务在CentOS上QPS 12万在Windows Server上只有3.2万——根源就在SelectorProvider的实现差异。因此内容设计包含JVM源码级分析sun.nio.ch.EPollSelectorImpl的doSelect()如何解析epoll_wait()返回的就绪事件Unsafe类如何通过allocateMemory()申请堆外内存甚至-XX:UseG1GC对DirectByteBuffer回收的影响G1 GC会扫描DirectByteBuffer的cleaner链表。这些细节不是炫技而是当你线上出现java.lang.OutOfMemoryError: Direct buffer memory时唯一能救命的线索。3. 核心细节解析与实操要点从文件描述符到BIO/NIO的硬核拆解3.1 文件描述符不只是数字是内核发放的资源许可证文件描述符File Descriptor常被简化为“整数编号”但这掩盖了它的本质它是进程访问内核资源的句柄承载着权限、状态、引用计数三重语义。在Linux中每个进程都有独立的files_struct结构体其中fdtab数组存储着struct file*指针。fd0/1/2stdin/stdout/stderr是shell启动时由内核预分配的而open()或socket()返回的fd是内核在fdtab中找到第一个空闲索引如fd3后将新创建的struct file对象地址填入该位置。关键细节在于struct file中f_flags字段记录着O_RDONLY、O_NONBLOCK等标志f_count是引用计数f_op指向操作函数集。这意味着dup(2)系统调用只是增加f_count并返回新fd而close(2)会递减f_count仅当计数归零时才真正释放资源。我曾用lsof -p $(pidof java)排查过一个泄漏问题某服务fd数持续增长lsof显示大量REG类型文件普通文件和IPv4类型socket但netstat -an | grep :8080却看不到对应连接——最终定位到是FileInputStream未关闭f_count未归零导致内核无法释放struct file。实操要点永远用try-with-resources或显式close()因为JVM的finalize()方法在G1 GC中已废弃依赖它释放fd等于埋雷。3.2 阻塞IO(BIO)线程挂起背后的内核调度真相BIO的“阻塞”二字常被误解为“线程卡死”。实际上当Java线程调用InputStream.read()JVM最终执行read(2)系统调用内核检查socket接收缓冲区若无数据内核将当前进程的task_struct状态设为TASK_INTERRUPTIBLE将其加入该socket的等待队列sk-sk_wq-wait然后调用schedule()让出CPU。此时线程在java.lang.Thread.State: WAITING (on object monitor)状态但内核视角是Ssleeping状态。关键参数在于SO_RCVTIMEO套接字选项若设置超时内核会在定时器到期后唤醒进程并返回EAGAIN若未设置进程将无限期等待。我在线上遇到过典型故障某HTTP客户端未设置setSoTimeout()上游服务宕机后1000个线程全部卡在read()jstack显示全在java.net.SocketInputStream.socketRead0()而ps aux --sort-pcpu显示CPU空闲——因为线程都在内核睡眠队列里。解决方案不是加线程而是用socket.setSoTimeout(5000)强制超时。实操心得BIO的线程数必须大于等于最大并发连接数否则会出现java.lang.OutOfMemoryError: unable to create new native thread因为每个线程栈默认1MB1000线程就是1GB内存。3.3 非阻塞IO(NIO)用户态轮询的代价与收益NIO的“非阻塞”常被误认为“不等待”实则是将等待行为从内核态转移到用户态并由应用自主决策。当SocketChannel.configureBlocking(false)后read()调用内核recvfrom(2)时内核检测到O_NONBLOCK标志且缓冲区为空立即返回-1并置errnoEAGAINLinux或WSAEWOULDBLOCKWindows。JVM捕获此错误后抛出java.io.IOException: Resource temporarily unavailable。此时应用需自行处理可立即重试busy-wait耗CPU、休眠后重试低效、或注册到Selector等待事件。Selector的魔法在于epoll_wait()它让内核监控多个fd的就绪状态当任一fd有数据可读时epoll_wait()返回就绪fd列表应用再逐个read()。我实测过纯轮询vsSelector1000个连接下纯轮询read()每秒触发200万次系统调用CPU 100%Selector每秒仅10次epoll_wait()调用CPU 15%。但NIO有隐藏成本ByteBuffer的flip()/compact()操作涉及数组边界计算Selector.select()返回的就绪事件需遍历处理这些在BIO中由内核隐式完成。实操警告Selector必须配合OP_READ/OP_WRITE事件注册若忘记interestOps(OP_READ)select()永远不返回就绪ByteBuffer容量不足时read()会静默截断需检查buffer.remaining()。3.4 网络通信与IO的耦合点socket缓冲区与内存拷贝链路网络通信的IO本质是数据在socket缓冲区与应用缓冲区之间的搬运。Linux socket有两层缓冲区接收缓冲区sk-sk_receive_queue和发送缓冲区sk-sk_write_queue。当网卡收到数据包DMA引擎将其写入内核内存IP层校验后放入接收缓冲区应用调用read()时内核将数据从接收缓冲区拷贝到用户空间byte[]或ByteBuffer。这个拷贝过程是性能杀手一次TCP读需4次拷贝网卡→内核缓冲区→内核临时页→用户空间而sendfile(2)可减少到2次磁盘page cache→网卡。Java中FileChannel.transferTo()正是调用sendfile(2)。我优化静态资源服务时将FileInputStream读取SocketOutputStream.write()改为Channels.newChannel(socket.getOutputStream()).write(fileChannel.map(...))QPS从8000提升到22000。关键参数/proc/sys/net/core/rmem_default控制接收缓冲区默认大小通常212992字节/proc/sys/net/core/wmem_default控制发送缓冲区。实操技巧用ss -i命令查看socket详细信息rcv_space字段即当前接收缓冲区可用空间若长期接近0说明应用读取太慢需优化read()逻辑或增大缓冲区。3.5 JAVA IO家族全景java.io、java.net、java.nio的血缘关系标题中“JAVA中的IO”需厘清三大包的关系java.io是面向流的BIO封装java.net是网络通信的BIO抽象java.nio是面向缓冲区的NIO实现。三者并非替代关系而是演进互补。java.io的FileInputStream包装open(2)系统调用java.net的Socket包装socket(2)connect(2)而java.nio的FileChannel和SocketChannel则包装open(2)和socket(2)但通过Selector实现多路复用。血缘证据在源码SocketChannel.open()内部调用new SocketAdaptor(new Socket())而SocketAdaptor继承自AbstractSelectableChannel其implConfigureBlocking()方法最终调用IOUtil.configureBlocking(fd, block)后者执行ioctl(fd, FIONBIO, arg)系统调用。这意味着java.nio并未抛弃BIO内核而是用更高级的抽象复用它。实操陷阱java.io的BufferedInputStream与java.nio的ByteBuffer混用会导致数据错乱因为前者在用户空间维护缓冲区后者依赖内核缓冲区java.net.URLConnection默认使用BIO即使设置了setConnectTimeout()getInputStream().read()仍可能无限阻塞必须单独设置setReadTimeout()。4. 实操过程与核心环节实现手写BIO/NIO服务器验证原理4.1 手写BIO服务器暴露线程阻塞的原始形态我们用最简代码实现BIO服务器直击阻塞本质public class BioServer { public static void main(String[] args) throws IOException { ServerSocket serverSocket new ServerSocket(8080); System.out.println(BIO Server started on port 8080); while (true) { Socket clientSocket serverSocket.accept(); // 阻塞点1等待连接 System.out.println(Accepted connection from clientSocket.getRemoteSocketAddress()); // 为每个连接创建新线程 new Thread(() - { try (BufferedReader reader new BufferedReader( new InputStreamReader(clientSocket.getInputStream())); PrintWriter writer new PrintWriter(clientSocket.getOutputStream())) { String line; while ((line reader.readLine()) ! null) { // 阻塞点2等待数据 System.out.println(Received: line); writer.println(Echo: line); writer.flush(); } } catch (IOException e) { e.printStackTrace(); } finally { try { clientSocket.close(); } catch (IOException e) { e.printStackTrace(); } } }).start(); } } }关键观察点serverSocket.accept()和reader.readLine()都是阻塞调用。用jstack $(pidof java)查看线程栈会看到大量java.lang.Thread.State: RUNNABLE线程停在java.net.PlainSocketImpl.socketAccept()和java.net.SocketInputStream.socketRead0()。此时用strace -p $(pidof java) -e traceaccept,read,write跟踪会看到accept(12, ...)和read(13, ...)系统调用长时间无返回。这就是BIO的原始形态每个连接独占一个线程线程在内核等待队列中沉睡。实操验证用ab -n 1000 -c 100 http://localhost:8080/压测top显示100个Java线程%wa飙升至60%以上。4.2 手写NIO服务器Selector事件驱动的精妙编排NIO服务器的核心是Selector它将多个Channel注册到单个Selector由select()统一监控public class NioServer { public static void main(String[] args) throws IOException { // 创建Selector Selector selector Selector.open(); // 创建ServerSocketChannel ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.configureBlocking(false); // 关键设为非阻塞 serverChannel.bind(new InetSocketAddress(8080)); serverChannel.register(selector, SelectionKey.OP_ACCEPT); // 注册ACCEPT事件 System.out.println(NIO Server started on port 8080); while (true) { // 阻塞点等待任一Channel就绪但只阻塞1个线程 int readyChannels selector.select(); if (readyChannels 0) continue; // 遍历就绪的SelectionKey IteratorSelectionKey keyIterator selector.selectedKeys().iterator(); while (keyIterator.hasNext()) { SelectionKey key keyIterator.next(); keyIterator.remove(); // 必须移除否则下次select()还会返回 if (key.isAcceptable()) { // 处理新连接 ServerSocketChannel channel (ServerSocketChannel) key.channel(); SocketChannel clientChannel channel.accept(); clientChannel.configureBlocking(false); // 注册READ事件 clientChannel.register(selector, SelectionKey.OP_READ); System.out.println(New connection from clientChannel.getRemoteAddress()); } else if (key.isReadable()) { // 处理读事件 SocketChannel channel (SocketChannel) key.channel(); ByteBuffer buffer ByteBuffer.allocate(1024); int bytesRead channel.read(buffer); // 非阻塞read if (bytesRead 0) { buffer.flip(); byte[] data new byte[buffer.remaining()]; buffer.get(data); String message new String(data); System.out.println(Received: message); // 回复 ByteBuffer response ByteBuffer.wrap((Echo: message).getBytes()); channel.write(response); } else if (bytesRead -1) { // 客户端关闭连接 channel.close(); System.out.println(Client closed connection); } } } } } }实操验证同样用ab -n 1000 -c 100压测jstack只看到1个main线程在sun.nio.ch.EPollArrayWrapper.epollWait()top显示CPU使用率稳定在15%%wa低于5%。用strace -p $(pidof java) -e traceepoll_wait,epoll_ctl,read,write跟踪会看到epoll_wait(3, ...)每秒调用约10次而read(13, ...)只在数据到达时触发。这证明NIO将“等待”集中化避免了BIO的线程爆炸。4.3 BIO/NIO性能对比实验量化阻塞与非阻塞的差距我们设计严谨对比实验排除干扰因素测试项BIO方案NIO方案线程模型1000个线程Executors.newFixedThreadPool(1000)1个线程Selector主循环JVM参数-Xms2g -Xmx2g -XX:UseG1GC同左额外-Djdk.nio.maxCachedBufferSize1048576客户端wrk -t12 -c1000 -d30s http://localhost:8080/同左监控指标jstat -gc $(pidof java) 1s,vmstat 1,ss -s同左实验结果CentOS 7.6, 32核64G吞吐量BIO QPS 4200NIO QPS 28500提升5.8倍延迟P99BIO 1280msNIO 42ms降低30倍内存占用BIO 3.2GB线程栈堆NIO 1.1GB堆外内存少量堆系统调用BIO每秒120万次read()NIO每秒8000次epoll_wait()2000次read()关键发现NIO的QPS优势在连接数500时才显著因为epoll_wait()的O(1)复杂度 vsselect()的O(n)。但NIO有隐藏成本ByteBuffer的allocateDirect()会触发mmap()系统调用频繁创建销毁DirectByteBuffer可能导致java.lang.OutOfMemoryError: Direct buffer memory。解决方案是用ByteBufferPool复用缓冲区或设置-XX:MaxDirectMemorySize2g。4.4 文件描述符泄漏实战排查从lsof到内核源码文件描述符泄漏是线上高频故障。我们模拟一个典型泄漏场景public class FdLeakDemo { public static void main(String[] args) throws Exception { while (true) { FileInputStream fis new FileInputStream(/dev/urandom); // 每次打开新fd // 忘记close() Thread.sleep(100); } } }实操排查步骤发现异常cat /proc/$(pidof java)/limits | grep Max open files查看fd上限通常1024lsof -p $(pidof java) | wc -l显示fd数持续增长定位类型lsof -p $(pidof java) -a -d 0-1024 | awk {print $5} | sort | uniq -c | sort -nr统计fd类型若REG文件或IPv4socket数量激增即为泄漏关联代码用jstack $(pidof java)找线程栈结合jmap -histo $(pidof java)看FileInputStream实例数终极验证echo 1 /proc/sys/vm/drop_caches清理page cache后lsof仍显示大量fd确认是代码级泄漏修复后验证lsof -p $(pidof java) | wc -l应稳定在20-50JVM自身fd。实操心得生产环境务必设置ulimit -n 65536并在Spring Boot中配置server.tomcat.max-connections10000避免fd耗尽导致java.net.BindException: Address already in use。4.5 JAVA NIO核心类源码剖析从Selector到Epoll深入java.nio源码理解NIO如何落地SelectorProviderSelector.open()调用SelectorProvider.provider().openSelector()Linux下返回EPollSelectorProvider其openSelector()创建EPollSelectorImplEPollSelectorImpldoSelect()方法调用EPollArrayWrapper.poll()后者执行epoll_wait(epollFd, events, timeout)系统调用EPollArrayWrapper管理epoll_event数组epollCtl()方法封装epoll_ctl(epollFd, op, fd, event)注册/注销fd事件SocketChannelImplread(ByteBuffer)调用IOUtil.read(fd, bb, position, nd)nd是NativeDispatcher最终调用IOUtil.write(fd, bb, position, nd)关键源码证据sun.nio.ch.IOUtil的read()方法中if (bb.hasRemaining()) { n IOUtil.read(fd, bb, position, nd); }n为返回值若n-1 errnoEAGAIN则返回0表示无数据。这证实了NIO的非阻塞本质是内核返回错误码而非JVM魔法。实操技巧用-Djava.nio.channels.spi.SelectorProvidersun.nio.ch.KQueueSelectorProvider可强制Mac使用kqueue避免epoll兼容问题。5. 常见问题与排查技巧实录线上故障的黄金排查清单5.1 BIO线程池耗尽从Thread State到OOM的连锁反应现象应用响应缓慢jstack显示大量线程在java.net.SocketInputStream.socketRead0()jstat -gc显示YGC频繁但FGC无dmesg有Out of memory: Kill process日志。根因链路serverSocket.accept()接受连接 → 创建Socket对象 →SocketInputStream初始化read()调用阻塞 → 线程进入WAITING状态 → JVM线程栈占用1MB内存1000个线程 1GB线程栈内存 → 触发Linux OOM Killer杀进程黄金排查步骤jstack $(pidof java) | grep java.net.SocketInputStream | wc -l统计阻塞线程数cat /proc/$(pidof java)/status | grep Threads:查看线程总数ps -mp $(pidof java) -o THREAD,tid,time | sort -k3r | head -20找CPU占用最高的线程jstack $(pidof java) | grep tid0x[0-9a-f]\ -A 10定位具体线程栈解决方案立即kill -3 $(pidof java)生成threaddump分析阻塞点短期增大-Xss256k降低单线程栈大小或ulimit -u 65536提高进程线程上限长期迁移到NIO或用Tomcat的maxThreads200限制BIO线程池提示BIO线程池的maxThreads不是越大越好。实测表明当线程数超过CPU核心数*2时上下文切换开销会抵消并发收益。32核服务器BIO线程池设为64最佳。5.2 NIO Selector空轮询CPU 100%的隐形杀手现象NIO服务CPU 100%jstack显示main线程在sun.nio.ch.EPollArrayWrapper.epollWait()但业务无流量。根因Linux内核epoll在特定条件下如epoll_wait()超时为0且无事件会返回0导致Selector.select()立即返回应用陷入while(true){select(); process();}空转。Java 6u21后引入epoll空轮询规避机制但某些内核版本仍有缺陷。黄金排查步骤strace -p $(pidof java) -e traceepoll_wait,epoll_ctl观察epoll_wait()调用频率若epoll_wait()每秒调用1000次且timeout0即为空轮询cat /proc/$(pidof java)/stack查看内核栈确认是否在sys_epoll_wait解决方案升级JDK到8u292或11.0.12内置空轮询规避临时修复-Djava.nio.channels.spi.SelectorProvidersun.nio.ch.PollSelectorProvider强制用poll(2)根本解决在select()后添加Thread.onSpinWait()JDK9或LockSupport.parkNanos(1)微休眠注意Thread.sleep(1)会触发线程状态切换开销大LockSupport.parkNanos(1000000)1ms是更优选择实测将CPU从100%降至5%。5.3 文件描述符耗尽从Too Many Open Files到连接拒绝现象java.net.ConnectException: Connection refusedjava.io.FileNotFoundException: /tmp/log.txt (Too many open files)netstat -an | grep :8080 | wc -l显示连接数远低于预期。根因链路Linux进程fd上限由ulimit -n控制默认1024lsof -p $(pidof java)显示REG文件、IPv4socket、anon_inodepipe等类型fd总和超限JVM的java.io类、java.nio的DirectByteBuffer、Log4j的FileAppender都会消耗fd黄金排查步骤ulimit -n查看当前限制lsof -p $(pidof java) | awk {print $5} | sort | uniq -c | sort -nr统计fd类型分布cat /proc/$(pidof java)/fd/ | wc -l精确统计fd数ss -s查看socket统计inuse字段即当前连接数解决方案立即ulimit -n 65536临时提升重启应用长期在/etc/security/limits.conf中设置java soft nofile 65536java hard nofile 65536代码层FileInputStream必须try-with-resourcesSocketChannel用完close()Log4j配置appender nameFILE classorg.apache.logging.log4j.core.appender.FileAppender并设置appendfalse5.4 BIO与NIO混合使用的灾难数据错乱与连接假死现象NIO服务偶尔返回乱码jstack显示java.nio.channels.ClosedChannelException客户端收到半截响应。根因java.io的BufferedInputStream与java.nio的SocketChannel混用。BufferedInputStream在用户空间维护8KB缓冲区SocketChannel.read()直接操作内核缓冲区两者对同一socket的读取位置不同步。黄金排查步骤检查代码中是否同时存在socket.getInputStream()和socket.getChannel()jstack中搜索ClosedChannelException定位close()调用点用tcpdump -i lo -w dump.pcap port 8080抓包用Wireshark分析TCP流重组解决方案绝对禁止混用选择java.io则全程用InputStream/OutputStream选择java.nio则用SocketChannelByteBuffer若必须桥接用Channels.newInputStream(socketChannel)包装但会损失NIO性能生产环境用netstat -an | grep :8080 | awk $6 ~ /ESTABLISHED/ {print $5} | cut -d: -f1 | sort | uniq -c | sort -nr监控客户端IP连接数防止单IP耗尽服务端fd5.5 JAVA IO性能拐点从GC压力到Direct Memory OOM现象服务运行数小时后java.lang.OutOfMemoryError: Direct buffer memoryjstat -gc显示G1 Old Gen使用率低jmap -histo无大对象。根因DirectByteBuffer分配堆外内存不受GC直接管理。其Cleaner