1. 这不是“学完就能做网站”的速成课而是Java网络编程的底层地基你点开这个标题大概率是刚学完Java基础语法正站在Web开发门口张望——手头有Tomcat、IDEA、一个空的Maven项目但敲下System.out.println(Hello World)之后突然卡在了“怎么让浏览器访问到我写的代码”这一步。别急这不是你一个人的困惑。我带过几十个从零起步的学员90%的人在接触Servlet之前对“网络编程”四个字的理解还停留在“用Socket写个聊天室”的Demo层面。而真正的JavaWeb远不止于此。它是一整套分层协作机制最底层是Java原生的java.net包提供的TCP/UDP通信能力中间层是HTTP协议解析与封装比如HttpURLConnection再往上才是Servlet规范定义的请求-响应生命周期最后才轮到Spring MVC这类框架做自动映射和参数绑定。这篇笔记不讲Spring Boot自动配置也不提前端Vue怎么调接口就死磕java.net包里那几个核心类Socket、ServerSocket、URL、URLConnection、InetAddress。为什么因为所有上层框架的“魔法”最终都要落地到这些类创建的连接、读取的字节流、构造的HTTP报文上。你见过哪个修车师傅不拆发动机就敢说懂汽车同理没亲手用DataInputStream从Socket里一行行读取HTTP请求头你永远不知道浏览器发来的GET请求里Host字段后面为什么跟着两个回车换行也不知道Content-Length为0时服务端该用什么方式判断请求体结束。这篇笔记会带你从零实现一个能返回静态HTML页面的微型HTTP服务器过程中你会亲手解析HTTP请求行、处理请求头、构造状态码、写入响应体——所有操作都基于JDK原生API不依赖任何第三方库。适合谁适合想真正理解Web本质的初学者也适合被框架封装“惯坏”、想找回底层掌控感的中级开发者。它不会让你明天就上线电商系统但它会让你看懂Tomcat源码里AbstractEndpoint类到底在做什么。2. 内容整体设计与思路拆解为什么从Socket开始而不是直接上Servlet2.1 拒绝“黑箱式学习”从物理连接到逻辑协议的逐层穿透很多教程一上来就让你新建一个WebServlet(/hello)然后request.getParameter(name)接着response.getWriter().println(Hello name)。这很高效但代价是彻底丢失了对网络通信本质的理解。就像教人开车只告诉你“踩油门走踩刹车停”却不解释内燃机原理、变速箱结构、轮胎与地面的摩擦力——一旦遇到“引擎异响”或“刹车失灵”你连排查方向都没有。JavaWeb的“引擎”就是java.net包。它的设计哲学非常朴素网络即字节流通信即读写操作。Socket对象本质上就是一个双向管道一端连着你的Java程序另一端连着远程主机的某个端口。你往这个管道里write()数据就变成电信号传出去你从这个管道里read()数据就从网线里涌进来。这种模型与文件IO几乎完全一致FileInputStream/FileOutputStream唯一的区别是数据源/目的地换成了网络。所以我们的设计起点必须是Socket而不是更高层的抽象。只有亲手用BufferedReader包装socket.getInputStream()一行行读取浏览器发来的原始HTTP请求你才会明白为什么HTTP协议规定请求行必须以\r\n结尾CRLF换行为什么Content-Length头存在时服务端必须严格按此字节数读取请求体否则后续请求会被截断为什么Connection: keep-alive会让同一个Socket被复用多次而close则意味着管道立即关闭。这种“字节级”的直觉是任何框架都无法替代的肌肉记忆。2.2 方案选型为何放弃NIO坚持BIO阻塞式IO作为教学主线当前主流高性能服务器如Netty、Tomcat NIO模式早已全面转向NIO非阻塞IO甚至AIO异步IO。但在这篇入门笔记中我坚持使用最原始的BIOServerSocket.accept()阻塞等待连接。原因有三第一心智负担最小。BIO模型与人类直觉完全吻合“我打开一扇门ServerSocket有人敲门客户端连接我就请他进来accept()返回一个Socket然后和他一对一聊天read()/write()”。而NIO需要理解Selector、Channel、Buffer、SelectionKey等概念还要处理OP_ACCEPT、OP_READ等事件注册对初学者而言这相当于还没学会走路就要学跑酷。第二调试成本最低。BIO的每一步操作都是同步、可预测的。你在socket.getInputStream().read()处打个断点程序必然停在这里直到有数据到达。而NIO的channel.read(buffer)可能返回0无数据、正数读到字节、-1连接关闭你需要额外逻辑判断调试时极易迷失在事件循环中。第三覆盖核心知识点无遗漏。BIO能100%覆盖HTTP协议解析、状态码构造、响应头设置、静态资源读取等所有关键环节。NIO的优势在于“单线程处理万级连接”但这属于性能优化范畴与“理解HTTP如何工作”这一核心目标无关。我们后续可以轻松地将BIO服务器升级为NIO版本但反之则不行——没理解BIO的阻塞本质你根本无法写出正确的NIO事件处理逻辑。提示本笔记所有代码均基于JDK 8无需额外依赖。java.net包是JDK标准库的一部分这意味着你复制粘贴代码后只要装了JDK就能立刻运行没有任何环境配置障碍。2.3 架构分层从“能跑通”到“可维护”的渐进式演进一个健壮的Web服务器绝不是把所有逻辑堆在一个main方法里。我们的代码结构将严格遵循分层原则每一层只解决一个明确问题网络层Network Layer负责ServerSocket的创建、监听、accept()连接以及Socket的输入/输出流获取。这是与操作系统网络栈打交道的唯一入口。协议层Protocol Layer专门解析HTTP请求HttpRequestParser和构造HTTP响应HttpResponseBuilder。它不关心数据从哪里来Socket还是文件只负责把原始字节流翻译成HttpRequest对象再把HttpResponse对象序列化成符合HTTP规范的字节流。业务层Business Layer处理具体的业务逻辑比如根据请求路径/index.html返回对应HTML文件内容或根据/api/user?id123查询用户数据。这一层与网络和协议完全解耦未来可以轻松替换为Spring MVC的Controller。资源层Resource Layer统一管理静态资源HTML/CSS/JS/图片的读取和MIME类型推断。它提供一个getResource(String path)方法业务层只需调用它无需关心文件系统路径或编码问题。这种分层不是为了炫技而是为了应对真实开发中的变化。比如某天你需要支持HTTPS只需在网络层替换ServerSocket为SSLServerSocket其他三层代码完全不动又或者你需要将静态资源托管到CDN只需重写资源层的getResource方法指向远程URL即可。这就是“高内聚、低耦合”的实际价值。3. 核心细节解析与实操要点那些文档里不会写的“坑”3.1ServerSocket的端口绑定为什么8080不是唯一选择但1024以下是禁区ServerSocket serverSocket new ServerSocket(8080);这行代码看似简单背后却藏着操作系统级别的权限规则。在Linux/Unix系统中端口号1-1023被称为“知名端口”Well-Known Ports例如HTTP的80、HTTPS的443、FTP的21。这些端口默认只能由root用户启动的进程绑定。如果你尝试new ServerSocket(80)会抛出java.net.BindException: Permission denied。因此开发阶段我们习惯用8080、8081、9000等大于1024的端口。但这并不意味着你可以随意选一个数字。实操中我踩过两个典型坑坑一端口已被占用。当你看到java.net.BindException: Address already in use第一反应是“是不是我上次没关程序”但更隐蔽的原因是某些系统服务如Skype、某些杀毒软件会默认监听5000、8080等常用端口。解决方案不是盲目换端口而是先用命令查清谁占用了它。Windows下执行netstat -ano | findstr :8080Linux/macOS下执行lsof -i :8080找到PID后用taskkill /PID PID /FWin或kill -9 PIDLinux/macOS干掉它。坑二localhostvs127.0.0.1vs0.0.0.0。new ServerSocket(8080)默认绑定到127.0.0.1这意味着只有本机localhost能访问。如果你想让同一局域网内的手机或平板也能访问你的服务器比如测试移动端适配就必须绑定到0.0.0.0即监听所有网卡。代码写法是new ServerSocket(8080, 50, InetAddress.getByName(0.0.0.0))其中第二个参数50是backlog队列长度等待连接的队列大小第三个参数指定绑定地址。InetAddress.getByName(0.0.0.0)是关键它告诉操作系统“我不挑网卡所有进来的连接都接住”。3.2 HTTP请求解析为什么不能用readLine()直接读取整个请求初学者常犯的错误是BufferedReader reader new BufferedReader(new InputStreamReader(socket.getInputStream())); String line reader.readLine();然后期待line里包含完整的HTTP请求。这是致命的误解。HTTP请求由三部分组成请求行Request Line、请求头Headers、请求体Body它们之间用空行\r\n\r\n分隔。而readLine()方法会自动剥离行尾的\r\n导致你无法准确判断空行的位置。更严重的是当请求体存在如POST表单提交时readLine()会把二进制文件上传数据如图片当作文本读取造成乱码和数据损坏。正确的做法是用字节流InputStream而非字符流InputStreamReader读取避免字符编码干扰手动查找\r\n\r\n字节序列定位请求头与请求体的边界对请求头部分再用String(byte[], charset)转换为字符串解析对请求体部分根据Content-Length或Transfer-Encoding头决定读取方式。下面这段代码是经过千锤百炼的解析核心// 1. 读取所有字节到内存仅适用于小请求大文件需流式处理 ByteArrayOutputStream buffer new ByteArrayOutputStream(); byte[] temp new byte[1024]; int len; while ((len inputStream.read(temp)) ! -1) { buffer.write(temp, 0, len); // 关键检查是否已读到请求头结束标记 \r\n\r\n if (buffer.size() 4) { byte[] last4 buffer.toByteArray(); int pos last4.length - 4; if (last4[pos] \r last4[pos1] \n last4[pos2] \r last4[pos3] \n) { break; // 找到空行停止读取请求头 } } } byte[] rawRequest buffer.toByteArray(); // 2. 分割请求头和请求体 int headerEnd indexOf(rawRequest, \r\n\r\n.getBytes()); if (headerEnd -1) throw new IllegalArgumentException(Invalid HTTP request: no header end); String headerStr new String(rawRequest, 0, headerEnd, StandardCharsets.ISO_8859_1); byte[] bodyBytes Arrays.copyOfRange(rawRequest, headerEnd 4, rawRequest.length);注意这里用了ISO_8859_1编码解析请求头。这是HTTP/1.1规范强制要求的因为请求头如User-Agent、Accept可能包含非ASCII字符而ISO_8859_1能无损映射所有0-255字节值。千万别用UTF-8否则中文User-Agent会乱码。3.3 响应头构造Content-Type和Content-Length的生死时速一个合法的HTTP响应至少需要三个响应头HTTP/1.1 200 OK状态行、Content-Type、Content-Length。漏掉任何一个浏览器都可能无法正确渲染。Content-Type告诉浏览器“我给你的是什么类型的文件”。对于HTML必须是text/html;charsetUTF-8对于CSS是text/css对于PNG图片是image/png。这里有个大坑charsetUTF-8必须显式声明否则浏览器可能用GBK或ISO-8859-1解析HTML导致中文全变成方块。Content-Length告诉浏览器“接下来我要发多少字节的数据”。这个值必须精确到字节多1少1都不行。计算方式是responseBody.getBytes(StandardCharsets.UTF_8).length。切记不能用responseBody.length()因为Java字符串的length()返回的是Unicode字符数而UTF-8编码下一个中文字符占3个字节你好.length()是2但你好.getBytes(UTF_8).length是6。下面是一个生产环境可用的响应头模板HTTP/1.1 200 OK\r\n Content-Type: text/html;charsetUTF-8\r\n Content-Length: 1234\r\n Connection: close\r\n \r\n注意最后的\r\n\r\n是响应头与响应体的分隔符一个都不能少。我曾因少写一个\r\n导致浏览器一直转圈等待数据排查了两小时才发现是响应头格式错误。4. 实操过程与核心环节实现从零搭建一个可运行的微型HTTP服务器4.1 环境准备与项目结构拒绝“一个.java文件走天下”虽然JavaWeb可以单文件运行但为了后续扩展性我们采用标准Maven结构。创建目录如下javaweb-notes/ ├── pom.xml └── src/ └── main/ ├── java/ │ └── com/example/web/ │ ├── server/ │ │ ├── SimpleHttpServer.java // 主启动类 │ │ └── NetworkLayer.java // 网络层ServerSocket管理 │ ├── protocol/ │ │ ├── HttpRequest.java // 请求对象 │ │ ├── HttpRequestParser.java // 请求解析器 │ │ ├── HttpResponse.java // 响应对象 │ │ └── HttpResponseBuilder.java // 响应构建器 │ ├── handler/ │ │ └── StaticResourceHandler.java // 业务层静态资源处理器 │ └── resource/ │ └── ResourceLoader.java // 资源层文件读取与MIME推断 └── resources/ └── static/ // 静态资源根目录 ├── index.html └── style.csspom.xml只需最简依赖project xmlnshttp://maven.apache.org/POM/4.0.0 modelVersion4.0.0/modelVersion groupIdcom.example/groupId artifactIdjavaweb-notes/artifactId version1.0-SNAPSHOT/version properties maven.compiler.source8/maven.compiler.source maven.compiler.target8/maven.compiler.target /properties /project这种结构的好处是每个.java文件只做一件事。SimpleHttpServer.java只负责启动和关闭HttpRequestParser.java只负责解析StaticResourceHandler.java只负责根据路径找文件。当你需要添加新功能如日志记录只需在NetworkLayer里加一个Logger成员变量所有连接日志自动输出无需修改其他任何文件。4.2 网络层实现NetworkLayer——让服务器真正“在线”NetworkLayer是整个服务器的“心脏起搏器”它封装了ServerSocket的所有复杂操作。核心代码如下public class NetworkLayer { private final int port; private final InetAddress bindAddress; private ServerSocket serverSocket; private volatile boolean isRunning false; public NetworkLayer(int port) { this(port, null); } public NetworkLayer(int port, String bindAddress) { this.port port; this.bindAddress bindAddress null ? InetAddress.getLoopbackAddress() : getInetAddress(bindAddress); } private InetAddress getInetAddress(String address) { try { return InetAddress.getByName(address); } catch (UnknownHostException e) { throw new RuntimeException(Invalid bind address: address, e); } } public void start() throws IOException { // 创建ServerSocket设置SO_REUSEADDR避免TIME_WAIT端口占用 serverSocket new ServerSocket(); serverSocket.setReuseAddress(true); serverSocket.bind(new InetSocketAddress(bindAddress, port), 50); isRunning true; System.out.printf(Server started on %s:%d%n, bindAddress.getHostAddress(), port); // 主循环接受连接 while (isRunning) { Socket clientSocket null; try { clientSocket serverSocket.accept(); // 为每个连接创建独立线程处理BIO典型模式 new Thread(() - handleClient(clientSocket)).start(); } catch (IOException e) { if (isRunning) { // 只有在主动关闭时忽略异常 System.err.println(Accept failed: e.getMessage()); } } } } private void handleClient(Socket socket) { try { // 设置超时防止恶意客户端长时间占用连接 socket.setSoTimeout(30000); // 30秒无数据则断开 InputStream in socket.getInputStream(); OutputStream out socket.getOutputStream(); // 解析请求 HttpRequest request HttpRequestParser.parse(in); System.out.printf(Received %s %s from %s%n, request.getMethod(), request.getPath(), socket.getRemoteSocketAddress()); // 处理请求并生成响应 HttpResponse response StaticResourceHandler.handle(request); // 写入响应 out.write(response.toBytes()); out.flush(); } catch (Exception e) { System.err.println(Error handling client: e.getMessage()); } finally { try { socket.close(); } catch (IOException ignored) {} } } public void stop() throws IOException { isRunning false; if (serverSocket ! null !serverSocket.isClosed()) { serverSocket.close(); } System.out.println(Server stopped.); } }关键点解析setReuseAddress(true)允许bind()时重用处于TIME_WAIT状态的端口。没有它每次重启服务器都会报Address already in use必须等2分钟才能再次启动。setSoTimeout(30000)为每个Socket设置30秒读取超时。这是防御DDoS攻击的第一道防线——如果客户端只建立连接但不发送数据30秒后自动断开释放线程资源。new Thread(...).start()BIO的典型并发模型。每个连接独占一个线程简单粗暴易于理解。当然线程数过多会耗尽系统资源这就是NIO要解决的问题但那是下一篇笔记的内容。4.3 协议层实现HttpRequestParser与HttpResponseBuilder——字节与协议的翻译官HttpRequestParser的核心任务是将原始字节流翻译成HttpRequest对象。其parse(InputStream in)方法逻辑如下读取所有字节到内存缓冲区如前所述手动查找\r\n\r\n分割请求头与请求体解析请求行按空格分割GET /path?query HTTP/1.1提取方法、路径、协议版本解析请求头按行分割每行用冒号:分割键值去除首尾空格解析查询参数Query String对?name张三age25进行URL解码和键值对拆分解析表单数据Form Data当Content-Type为application/x-www-form-urlencoded时对请求体做同样处理。HttpRequest类设计为不可变对象Immutable所有字段final确保线程安全public final class HttpRequest { private final String method; private final String path; private final String queryString; private final MapString, String headers; private final MapString, String parameters; // 合并query string和form data private final byte[] body; // 构造函数省略确保所有字段在创建时赋值 }HttpResponseBuilder则负责反向操作将HttpResponse对象序列化为符合HTTP规范的字节流。其toBytes()方法生成完整的响应public byte[] toBytes() { StringBuilder sb new StringBuilder(); sb.append(HTTP/1.1 ).append(statusCode).append( ).append(reasonPhrase).append(\r\n); for (Map.EntryString, String header : headers.entrySet()) { sb.append(header.getKey()).append(: ).append(header.getValue()).append(\r\n); } sb.append(\r\n); // 空行分隔头与体 byte[] headerBytes sb.toString().getBytes(StandardCharsets.ISO_8859_1); byte[] bodyBytes this.body ! null ? this.body : new byte[0]; // 合并头和体 byte[] result new byte[headerBytes.length bodyBytes.length]; System.arraycopy(headerBytes, 0, result, 0, headerBytes.length); System.arraycopy(bodyBytes, 0, result, headerBytes.length, bodyBytes.length); return result; }这里再次强调ISO_8859_1HTTP规范要求响应头必须用此编码而响应体如HTML的编码由Content-Type头中的charset指定两者独立。4.4 业务层与资源层StaticResourceHandler与ResourceLoader——让服务器“有内容可返回”StaticResourceHandler.handle(HttpRequest)是业务逻辑的入口。它的工作流程是规范化请求路径将/../../etc/passwd这样的路径遍历攻击转换为安全路径映射到文件系统将/index.html映射到src/main/resources/static/index.html加载资源调用ResourceLoader.getResource(path)读取文件内容推断MIME类型根据文件扩展名.html→text/html.png→image/png构造响应设置状态码200、Content-Type、Content-Length写入文件字节。ResourceLoader的关键在于安全的文件读取public class ResourceLoader { private static final String STATIC_ROOT static/; public static Resource getResource(String requestPath) { // 1. 移除开头的/ String cleanPath requestPath.startsWith(/) ? requestPath.substring(1) : requestPath; // 2. 防止路径遍历拒绝包含..的路径 if (cleanPath.contains(..)) { return new Resource(null, 400, Bad Request); } // 3. 拼接资源路径 String resourcePath STATIC_ROOT cleanPath; // 4. 从classpath加载Maven标准位置 InputStream is ResourceLoader.class.getClassLoader() .getResourceAsStream(resourcePath); if (is null) { return new Resource(null, 404, Not Found); } try { byte[] content is.readAllBytes(); String mimeType getMimeType(cleanPath); return new Resource(content, 200, OK, mimeType); } catch (IOException e) { return new Resource(null, 500, Internal Server Error); } } private static String getMimeType(String path) { String ext getFileExtension(path); switch (ext.toLowerCase()) { case html: case htm: return text/html; case css: return text/css; case js: return application/javascript; case png: return image/png; case jpg: case jpeg: return image/jpeg; default: return application/octet-stream; } } private static String getFileExtension(String path) { int dotIndex path.lastIndexOf(.); return dotIndex -1 ? : path.substring(dotIndex 1); } }Resource类是一个简单的数据载体封装了响应体字节、状态码、状态文本和MIME类型。getResourceAsStream()是从classpath即src/main/resources加载资源的标准方式比直接读取文件系统路径更可靠且能打包进JAR文件后正常工作。5. 常见问题与排查技巧实录那些让我熬夜到凌晨三点的Bug5.1 问题速查表高频故障与一键修复方案问题现象可能原因排查步骤修复方案浏览器显示“连接已重置”或“ERR_CONNECTION_RESET”服务端未正确发送响应或发送后立即关闭Socket1. 用telnet localhost 8080手动连接2. 输入GET / HTTP/1.1\r\nHost: localhost\r\n\r\n注意两个\r\n3. 观察是否有响应返回检查HttpResponseBuilder.toBytes()是否包含了完整的\r\n\r\n分隔符确认out.flush()被调用确保socket.close()在响应发送完毕后才执行HTML页面中文显示为方块响应头未声明charsetUTF-8或响应体编码与声明不符1. 在浏览器开发者工具F12的Network标签页查看Response Headers2. 检查Content-Type值是否为text/html;charsetUTF-8在HttpResponseBuilder中Content-Type头必须显式包含;charsetUTF-8确保body.getBytes(UTF_8)与Content-Length计算一致POST请求参数始终为空未解析请求体或解析时编码错误1. 在HttpRequestParser中打印原始请求字节流2. 检查是否正确识别了Content-Type: application/x-www-form-urlencoded确保HttpRequestParser在检测到application/x-www-form-urlencoded时对请求体字节流调用new String(bodyBytes, StandardCharsets.UTF_8)解码再按和分割服务器启动后第二次访问就卡死ServerSocket.accept()阻塞但处理线程未正确关闭Socket1. 用jstack pid查看线程堆栈2. 搜索java.net.PlainSocketImpl.accept在handleClient()的finally块中必须确保socket.close()被执行即使发生异常也要关闭添加try-catch包裹socket.close()防止二次异常静态资源CSS/JS404但HTML能正常访问资源路径映射错误或MIME类型推断失败1. 在ResourceLoader.getResource()中添加日志打印resourcePath2. 检查src/main/resources/static/目录下文件是否存在确保STATIC_ROOT常量与实际目录结构一致检查文件扩展名拼写如style.CSS应为style.css在getMimeType()中添加default分支的日志5.2 独家避坑技巧来自血泪教训的实战经验技巧一用telnet代替浏览器进行原子级调试浏览器是一个过于复杂的HTTP客户端它会自动处理重定向、缓存、Cookie、HTTPS降级等。当你怀疑是协议层问题时立刻扔掉浏览器用telnet localhost 8080进入原始字节世界。手动输入GET /test.html HTTP/1.1 Host: localhost Connection: close注意Host头是HTTP/1.1强制要求的Connection: close确保单次请求后断开避免keep-alive干扰然后观察返回的原始字节。如果返回HTTP/1.1 200 OK和HTML内容说明协议层完全正确如果返回400 Bad Request说明请求头格式有误如果无响应说明服务端卡在读取阶段。这是定位网络和协议问题的黄金标准。技巧二在关键节点添加“字节快照”日志不要只打印System.out.println(Request path: request.getPath())。在HttpRequestParser.parse()的开头打印原始请求的前100个字节System.out.println(Raw request bytes (hex): HexFormat.of().formatHex(Arrays.copyOf(rawRequest, Math.min(100, rawRequest.length))));HexFormat.of().formatHex()是JDK 17的新API如果用旧版JDK可用String.format(%02x, b)循环拼接。十六进制日志能清晰暴露\r\n、空格、中文编码等细节比纯字符串日志可靠十倍。技巧三用curl -v查看完整HTTP事务curl -v http://localhost:8080/会显示完整的请求头、响应头和响应体包括状态码、重定向跳转、SSL握手信息。比浏览器开发者工具更底层、更透明。特别适合验证Content-Length是否准确、Content-Type是否正确。技巧四线程安全的终极保障——日志时间戳线程ID在多线程BIO服务器中日志混杂是常态。在System.out.println()前加上线程标识System.out.printf([%s] %s%n, Thread.currentThread().getName(), Server started);这样你能一眼看出哪条日志来自哪个线程快速定位是主线程崩溃还是工作线程异常。注意以上所有技巧我都曾在真实项目中反复使用。它们不是教科书里的理论而是我在凌晨三点对着满屏日志抓狂时亲手验证过的救命稻草。记住调试的本质不是“猜”而是“证伪”——用最原始的工具telnet/curl和最直接的数据十六进制字节一步步排除不可能的选项真相自然浮现。6. 性能与安全加固从“能跑”到“能用”的最后一公里6.1 连接管理如何优雅地处理海量并发连接BIO模型的天然缺陷是“一个连接一个线程”线程数上限受操作系统限制Linux默认约1024。当并发连接超过此数accept()会阻塞新连接无法接入。解决方案不是立刻上NIO而是先做轻量级优化连接池化对数据库连接、Redis连接等外部资源必须使用HikariCP、Lettuce等专业连接池避免每次请求都新建连接。线程池替代裸线程将new Thread(...).start()替换为Executors.newFixedThreadPool(50)限制最大工作线程数为50。这样即使有1000个连接请求也只有50个线程在工作其余在队列中等待避免系统崩溃。超时控制三重保险Socket.setSoTimeout(30000)单次读取超时ServerSocket.setSoTimeout(5000)accept()超时避免主线程永久阻塞工作线程内设置Future.get(30, TimeUnit.SECONDS)业务逻辑执行超时强制中断。6.2 安全加固堵住那些教科书里不提的漏洞路径遍历防护ResourceLoader中已实现cleanPath.contains(..)检查但这只是基础。更严谨的做法是Path basePath Paths.get(src/main/resources/static).toAbsolutePath(); Path resourcePath basePath.resolve(cleanPath).normalize(); if (!resourcePath.startsWith(basePath)) { throw new SecurityException(Path traversal attempt detected); }Paths.get().normalize()会自动处理/a/b/../c变为/a/cstartsWith(basePath)确保最终路径仍在白名单目录内。HTTP头注入防护用户输入的参数如?namescriptalert(1)/script如果直接拼接到响应体中会造成XSS。解决方案是对HTML响应体使用StringEscapeUtils.escapeHtml4()Apache Commons Text转义