企业官网建设流程全解析

1. 项目概述：当WebSocket遇上“长篇大论”

在实时通信领域，WebSocket早已不是新鲜事物，它凭借全双工、低延迟的特性，成为构建聊天室、实时数据看板、在线协作编辑等应用的基石。然而，在实际开发中，尤其是使用Java技术栈时，一个看似简单却常被忽略的“坑”会突然出现：发送长文本消息。你可能顺利地处理了心跳、连接管理、甚至二进制帧，但当客户端需要发送一篇冗长的JSON配置、一个复杂的HTML片段，或者一段包含大量数据的日志时，连接突然断开、消息被截断、或者服务器直接抛出异常。这不仅仅是“文本太长”这么简单，其背后涉及到WebSocket协议规范、服务器实现、客户端处理以及网络传输层的多重限制与交互逻辑。

这个问题之所以棘手，是因为它通常不会在开发初期或测试短消息时暴露。只有当业务量增长，数据体量变大后，它才会像一颗定时炸弹一样引爆。更麻烦的是，不同的WebSocket服务器实现（如Tomcat、Jetty、Undertow）对长文本的处理策略和默认限制可能不同，而RFC 6455协议本身也对数据帧的大小有建议性约束。因此，解决“Java实现WebSocket发送长文本问题”不是一个简单的调大某个参数就能搞定的事情，它需要开发者对协议层、应用层乃至网络层有一个连贯的理解。

本文将从一个踩过坑的开发者视角，深度拆解这个问题的成因、表现、以及一套从诊断到根治的完整解决方案。无论你使用的是Spring Boot内置的WebSocket支持，还是直接基于javax.websocketAPI或Netty进行开发，其中的核心原理和解决思路都是相通的。我们会从协议限制讲起，剖析服务器容器的默认行为，再深入到代码层面的分片、流式处理等高级策略，最后分享一套经过线上验证的稳定性方案。目标不仅是让你能发送长文本，更是要构建一个健壮的、可应对各种边界情况的实时消息系统。

2. 核心问题诊断：长文本为何“难产”？

在开始动手解决之前，我们必须先像医生一样，准确地诊断出病症所在。发送长文本失败，表象可能是连接关闭、消息丢失或异常，但根源可能分布在以下几个层面。

2.1 WebSocket协议帧的长度限制

WebSocket协议以“帧”为单位传输数据。根据RFC 6455，单个数据帧的负载长度由帧头中的“有效负载长度”字段表示。这个字段的设计决定了其表征能力：

• 7位： 表示长度在0-125字节之间。
• 16位： 当长度为126时，后续2字节表示一个16位无符号整数，最大长度为65535字节（约64KB）。
• 64位： 当长度为127时，后续8字节表示一个64位无符号整数，理论长度上限极高（2^63-1字节）。

从协议上看，似乎支持非常大的单帧。但关键在于，协议规范明确建议，为了防止中间件（如代理服务器）或某些实现出现缓冲区问题，应用层应避免发送过大的帧。许多服务器和客户端库会遵循这个建议，设置一个默认的最大帧大小或最大消息大小阈值。一旦超出，它们可能选择：

1. 拒绝该帧并关闭连接。
2. 尝试处理但因缓冲区不足而失败。
3. 在内部进行分片（但行为不统一）。

因此，第一个检查点就是：你的服务器和客户端配置的最大文本消息缓冲区大小或最大帧大小是多少？

2.2 服务器容器的默认配置与差异

Java生态中常见的WebSocket服务器实现，其默认限制往往成为“沉默的杀手”。

• Tomcat (版本8.5及以上, 9, 10)： 默认的maxTextMessageBufferSize是8192字节（8KB）。这意味着，任何超过8KB的文本消息，如果没有显式配置，Tomcat会在尝试解码时抛出org.apache.tomcat.websocket.MessageTooLargeException异常，并可能导致连接关闭。

  // Tomcat 抛出异常的核心逻辑示意 if (textMessage.length() > maxTextMessageBufferSize) { throw new MessageTooLargeException(...); }

• Jetty： Jetty的默认行为相对宽松一些，但其org.eclipse.jetty.websocket.api.WebSocketPolicy中也定义了getMaxTextMessageSize()，默认值通常是65536字节（64KB）。超过此限制，行为可能是丢弃消息或关闭会话。

• Undertow： 通过io.undertow.websockets.core.WebSocketChannel配置，也有类似的限制参数。

• Spring Boot的WebSocket支持： Spring Boot通过自动配置简化了集成，但它底层依然依赖于上述容器。在Spring Boot 2.x中，如果你使用@ServerEndpoint，需要通过ServerEndpointConfig.Configurator来配置；如果使用WebSocketHandler，则需要通过WebSocketTransportRegistration来设置消息大小限制。

诊断方法： 查看服务器日志。寻找类似MessageTooLargeException、Buffer overflow、Session closed等关键字。同时，在客户端捕获onClose事件，检查关闭代码和原因，WebSocket协议定义了一些特定的关闭码，如1009 - Message too big，这能直接指明问题。

2.3 应用层代码的隐式瓶颈

即使服务器容器允许大消息，你的应用层代码也可能成为瓶颈。

1. 同步发送阻塞： 在@OnMessage方法中直接处理一个超长字符串，并进行复杂的业务逻辑（如JSON解析、数据库操作），如果这个过程是同步的，它会长时间占用WebSocket工作线程。对于Tomcat等使用线程池的容器，这可能导致线程耗尽，影响其他连接的响应。
2. 内存占用： 在内存中持有完整的、未经处理的长文本消息（例如，一个几十MB的字符串），会瞬间推高JVM堆内存使用，可能触发GC甚至OOM。String对象在Java中是不可变的，一个巨大的字符串对内存非常不友好。
3. 序列化/反序列化开销： 如果消息是复杂的JSON或XML，在服务器端进行完整的反序列化（例如，用Jackson映射成一个巨大的Java对象）可能消耗大量CPU和内存，且容易在数据格式稍有瑕疵时抛出异常，导致整个消息处理失败。

注意： 不要仅仅依赖“调大缓冲区”这种粗暴方式。无限制地增大maxTextMessageBufferSize相当于移除了一个安全阀，一个恶意的客户端或一次意外的数据激增，就可能通过一个超大的消息拖垮你的服务器线程或内存。

3. 解决方案一：调整服务器容器配置（基础步骤）

这是最直接、最快速的解决方法，适用于消息长度可控、且不会无限增长的场景。目标是让服务器能够“接收”并“持有”完整的长消息。

3.1 Tomcat 配置调整

如果你使用独立的Tomcat部署WAR包，可以在context.xml或应用的WebSocket配置类中进行设置。

通过 Spring Boot 配置 (application.properties/yml): 这是最常用的方式。Spring Boot的自动配置为我们提供了便捷的入口。

# application.properties # 设置最大文本消息缓冲区大小为 1MB (1024 * 1024) server.tomcat.max-swallow-size=1MB # 专门针对WebSocket的文本消息缓冲区大小，Spring Boot 2.1+ 提供了更直接的配置 spring.websocket.server.tomcat.max-text-message-buffer-size=1048576

# application.yml spring: websocket: server: tomcat: max-text-message-buffer-size: 1048576 # 1MB server: tomcat: max-swallow-size: 1MB

• max-text-message-buffer-size： 直接控制Tomcat WebSocket处理文本消息时的缓冲区上限。
• max-swallow-size： 这是一个更底层的Tomcat连接器配置，表示Tomcat在处理上传数据（包括HTTP POST和WebSocket帧）时，在关闭连接前愿意“吞下”的最大字节数。将其设置为一个较大的值作为保障。

通过 Java Config 配置： 如果需要更精细的控制，可以定义一个WebSocketConfigurer或ServletWebSocketHandlerRegistry的配置Bean。

@Configuration @EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { @Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(myHandler(), "/ws") .setAllowedOrigins("*") // 关键：配置传输选项，设置消息大小限制 .setHandshakeHandler(handshakeHandler()) .withSockJS(); // 如果使用SockJS } @Bean public DefaultHandshakeHandler handshakeHandler() { TomcatRequestUpgradeStrategy strategy = new TomcatRequestUpgradeStrategy(); strategy.setMaxSessionIdleTimeout(30000L); // 创建策略并设置最大消息大小 WebSocketContainerFactoryBean factory = new WebSocketContainerFactoryBean(); factory.setMaxTextMessageBufferSize(1024 * 1024); // 1MB // ... 其他配置 return new DefaultHandshakeHandler(strategy); } // ... 其他Bean定义 }

对于纯@ServerEndpoint注解方式，你需要提供一个ServerEndpointConfig.Configurator：

@ServerEndpoint(value = "/ws", configurator = MyEndpointConfigurator.class) public class MyWebSocketEndpoint { // ... } public class MyEndpointConfigurator extends ServerEndpointConfig.Configurator { @Override public void modifyHandshake(ServerEndpointConfig sec, HandshakeRequest request, HandshakeResponse response) { // 这种方式对Tomcat内置容器的参数设置不直接，通常更推荐在容器层面配置 } } // 更有效的方式是通过ServerContainer来设置 @Bean public ServletServerContainerFactoryBean createWebSocketContainer() { ServletServerContainerFactoryBean container = new ServletServerContainerFactoryBean(); container.setMaxTextMessageBufferSize(1024 * 1024); // 1MB container.setMaxBinaryMessageBufferSize(1024 * 1024); // 1MB return container; }

3.2 Jetty 与 Undertow 配置

Jetty: 在Spring Boot中，可以通过属性配置：

# 设置Jetty WebSocket最大文本消息大小 spring.jetty.websocket.max-text-message-size=1048576

或者通过WebSocketServerFactory进行编程式配置。

Undertow: Undertow的配置相对隐蔽，通常通过WebSocketDeploymentInfo进行设置。在Spring Boot中，如果你使用了Undertow作为嵌入式容器，可以通过自定义UndertowServletWebServerFactory来配置：

@Bean public UndertowServletWebServerFactory undertowFactory() { UndertowServletWebServerFactory factory = new UndertowServletWebServerFactory(); factory.addDeploymentInfoCustomizers(deploymentInfo -> { WebSocketDeploymentInfo wsInfo = new WebSocketDeploymentInfo(); wsInfo.setBuffers(new DefaultByteBufferPool(false, 1024)); // 设置Worker线程IO缓冲区大小，间接影响WebSocket消息处理能力 // 对于消息大小的直接限制，Undertow更多依赖于XNIO的配置，或需要在Endpoint中处理 deploymentInfo.addServletContextAttribute(WebSocketDeploymentInfo.ATTRIBUTE_NAME, wsInfo); }); return factory; }

对于Undertow，更常见的做法是在应用层处理消息分片，而不是依赖容器缓冲整个消息。

配置后的验证： 调整配置后，务必进行压力测试。使用一个能发送特定长度文本的WebSocket客户端工具，逐步增加消息大小，观察服务器日志和客户端响应，确认在设定阈值内工作正常，并监控服务器的内存和线程使用情况。

4. 解决方案二：应用层消息分片与流式处理（根治方案）

单纯调大缓冲区是治标不治本。对于真正可能无限长或体积巨大的文本数据（如实时日志流、大型文档传输），必须在应用层实现分片或流式处理。这才是构建稳健系统的核心思路。

4.1 设计分片协议

我们需要在WebSocket之上，定义一套简单的应用层协议，将长文本切割成多个片段进行传输，在接收端重新组装。

消息格式设计： 我们可以定义两种类型的消息：

1. 分片开始消息： 包含消息ID、总片数、可选的消息类型或元数据。
2. 分片数据消息： 包含消息ID、片序号、数据内容。
3. 分片结束消息（可选）： 明确标识一个消息传输结束，可用于校验。

为了简化，我们可以将元数据和分片数据合并。例如，每个数据帧都是一个JSON对象：

// 发送端发出的每一“片” { "id": "unique_msg_123", // 唯一消息ID，用于组装 "index": 0, // 当前片序号（从0开始） "total": 5, // 总片数 "content": "这是第一片文本数据...", // 当前片的内容 "type": "TEXT" // 消息类型，可扩展 }

分片大小的选择： 分片大小需要权衡。太小会导致帧头开销比例高、网络往返次数多；太大则可能触碰到容器或中间网络的限制。一个经验值是8KB - 64KB之间。可以动态调整，例如固定为16KB。确保它远小于你配置的服务器maxTextMessageBufferSize。

4.2 发送端（客户端）实现

客户端负责将长文本切割并有序发送。这里以JavaScript客户端为例：

class FragmentedWebSocketSender { constructor(wsUrl) { this.ws = new WebSocket(wsUrl); this.pendingMessages = new Map(); // 可选，用于管理未确认的消息 } sendLongText(text, messageId = this.generateId()) { const CHUNK_SIZE = 16 * 1024; // 16KB const totalChunks = Math.ceil(text.length / CHUNK_SIZE); for (let i = 0; i < totalChunks; i++) { const start = i * CHUNK_SIZE; const end = start + CHUNK_SIZE; const chunk = text.substring(start, end); const fragment = { id: messageId, index: i, total: totalChunks, content: chunk, type: 'TEXT' }; // 确保WebSocket已连接 if (this.ws.readyState === WebSocket.OPEN) { this.ws.send(JSON.stringify(fragment)); } else { console.error('WebSocket is not open.'); break; } // 可选：在片之间添加微小延迟，避免瞬间压垮接收端或网络 // await new Promise(resolve => setTimeout(resolve, 1)); } console.log(`Message ${messageId} sent in ${totalChunks} fragments.`); } generateId() { return Date.now().toString(36) + Math.random().toString(36).substr(2); } }

4.3 接收端（Java服务端）实现

服务端需要维护一个临时缓存（如ConcurrentHashMap）来按messageId聚合分片。考虑到并发和内存管理，实现需要谨慎。

@Component @ServerEndpoint("/ws/fragment") public class FragmentedWebSocketEndpoint { // 用于存储正在组装的消息。Key: messageId, Value: 组装状态对象 private static final ConcurrentHashMap<String, MessageAssembler> assemblingMessages = new ConcurrentHashMap<>(); @OnMessage public void onMessage(Session session, String message) { try { // 1. 解析分片消息 JsonNode jsonNode = objectMapper.readTree(message); String msgId = jsonNode.get("id").asText(); int index = jsonNode.get("index").asInt(); int total = jsonNode.get("total").asInt(); String content = jsonNode.get("content").asText(); String type = jsonNode.get("type").asText(); // 2. 获取或创建组装器 MessageAssembler assembler = assemblingMessages.computeIfAbsent(msgId, k -> new MessageAssembler(total, type)); // 3. 存储分片 assembler.addFragment(index, content); // 4. 检查是否完成组装 if (assembler.isComplete()) { // 5. 组装完整消息 String fullMessage = assembler.assemble(); // 6. 从缓存中移除 assemblingMessages.remove(msgId); // 7. 处理完整的业务消息 processCompleteMessage(session, fullMessage, type); } } catch (Exception e) { log.error("Error processing message fragment: {}", message, e); // 可以考虑发送错误信息给客户端，或者清理对应的assembler } } @OnClose public void onClose(Session session, CloseReason reason) { // 可选：清理该session相关的未完成组装消息，防止内存泄漏 // 这需要更精细的管理，例如在assembler中记录sessionId } private void processCompleteMessage(Session session, String fullMessage, String type) { // 这里是你的业务逻辑 log.info("Received complete message of type {}: length={}", type, fullMessage.length()); try { if ("TEXT".equals(type)) { // 处理文本消息... session.getBasicRemote().sendText("Echo: " + fullMessage.substring(0, Math.min(100, fullMessage.length())) + "..."); } } catch (IOException e) { log.error("Failed to send response", e); } } // 内部类：消息组装器 private static class MessageAssembler { private final String[] fragments; private final String type; private final AtomicInteger receivedCount = new AtomicInteger(0); private final int totalFragments; public MessageAssembler(int totalFragments, String type) { this.totalFragments = totalFragments; this.fragments = new String[totalFragments]; this.type = type; } public synchronized void addFragment(int index, String content) { if (index >= 0 && index < totalFragments) { if (fragments[index] == null) { fragments[index] = content; receivedCount.incrementAndGet(); } else { log.warn("Duplicate fragment received for index: {}", index); } } } public boolean isComplete() { return receivedCount.get() == totalFragments; } public String assemble() { StringBuilder sb = new StringBuilder(); for (String frag : fragments) { if (frag != null) { sb.append(frag); } else { // 理论上不会发生，因为isComplete已检查 throw new IllegalStateException("Missing fragment during assembly"); } } return sb.toString(); } } }

关键要点与优化：

1. 内存管理：assemblingMessages是一个静态Map，会常驻内存。必须防止它无限增长。
   • 策略一：超时清理。为每个MessageAssembler添加创建时间戳，启动一个定时任务，定期扫描并清理长时间（如30秒）未完成的组装器。
   • 策略二：会话关联。将组装器与Session绑定，在@OnClose或@OnError时清理该会话的所有组装器。
   • 策略三：使用有界缓存。使用Guava的CacheBuilder或Caffeine缓存，设置最大容量和过期时间。
2. 并发安全：ConcurrentHashMap保证了assemblingMessages本身的安全，但MessageAssembler内部的addFragment和isComplete也需要同步控制，防止多线程操作同一组装器导致状态错乱。
3. 顺序保证： WebSocket协议本身保证单个连接上帧的顺序。但在分片场景下，我们依赖index字段进行排序组装，即使网络包乱序到达（在TCP/WebSocket层面几乎不可能），我们的逻辑也能正确处理。
4. 可靠性增强： 可以增加ACK机制。服务端每收到一个分片，向客户端发送一个确认。客户端在超时未收到ACK时重传。这对于高可靠性场景是必要的，但会显著增加复杂度。

4.4 流式处理进阶

对于极端长的数据（如GB级的文件），即使分片，在内存中组装成完整的String也可能导致OOM。此时需要流式处理。

思路是：不等待所有分片到达，而是每收到一个分片，就将其追加到一个临时文件或OutputStream中。当所有分片接收完毕，再对生成的文件进行后续处理（如解析、存储、转发）。这彻底避免了在内存中保存完整数据。

public class StreamingMessageAssembler { private final Path tempFile; private final FileChannel fileChannel; private final int totalFragments; private final AtomicInteger receivedCount = new AtomicInteger(0); // ... 其他字段 public StreamingMessageAssembler(String messageId, int totalFragments) throws IOException { this.totalFragments = totalFragments; this.tempFile = Files.createTempFile("ws_frag_" + messageId, ".dat"); this.fileChannel = FileChannel.open(tempFile, StandardOpenOption.WRITE); } public synchronized void addFragment(int index, byte[] data) throws IOException { // 这里假设分片是顺序的，或者我们需要更复杂的位置管理 // 简单起见，可以按顺序写入，非顺序分片需要缓存和排序逻辑 fileChannel.write(ByteBuffer.wrap(data)); receivedCount.incrementAndGet(); } public boolean isComplete() { return receivedCount.get() == totalFragments; } public Path getCompleteFile() throws IOException { fileChannel.close(); return tempFile; } public void cleanup() { try { if (fileChannel != null && fileChannel.isOpen()) { fileChannel.close(); } Files.deleteIfExists(tempFile); } catch (IOException e) { log.warn("Failed to clean up temp file: {}", tempFile, e); } } }

这种方式将内存压力转移到了磁盘I/O，适合处理超大消息。但需要注意临时文件的管理和清理。

5. 解决方案三：协议层优化与替代方案

除了在应用层动手脚，我们还可以从协议和架构层面思考。

5.1 使用二进制模式发送文本

WebSocket支持文本和二进制两种帧。有时，将文本数据以二进制帧发送可能更高效。二进制帧在传输过程中不会被强制进行UTF-8有效性校验（直到你将其转换为String），且一些库对二进制帧的缓冲区管理可能不同。

在客户端，你可以将文本encode为ArrayBuffer发送：

// JavaScript const text = "很长很长的文本..."; const encoder = new TextEncoder(); const data = encoder.encode(text); websocket.send(data); // 发送二进制帧

在服务端，@OnMessage方法需要接收ByteBuffer或byte[]：

@OnMessage public void onMessage(Session session, ByteBuffer byteBuffer) { String text = StandardCharsets.UTF_8.decode(byteBuffer).toString(); // 处理文本... }

这种方式绕过了“文本消息缓冲区”的大小限制，但受限于“二进制消息缓冲区”大小。不过，二进制缓冲区的默认值有时比文本缓冲区大。更重要的是，它为流式处理提供了更自然的接口（直接操作字节流）。

5.2 启用WebSocket扩展（如permessage-deflate）

RFC 7692定义了WebSocket的压缩扩展permessage-deflate。启用压缩后，文本数据在传输前会被压缩，有效载荷体积减小，从而间接缓解了长文本问题。大多数现代浏览器和服务器（如Tomcat 8+）都支持此扩展。

在Spring Boot中，默认可能是启用的，或者可以通过配置开启：

# 对于Tomcat，压缩通常在连接器级别配置，WebSocket会自动继承。 server.compression.enabled=true server.compression.mime-types=text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json # WebSocket压缩有单独的协商过程，通常无需额外配置。

压缩对于文本（尤其是重复内容多的JSON、XML）效果显著，但会增加服务器和客户端的CPU开销。需要权衡。

5.3 终极架构思考：长文本真的该用WebSocket发吗？

这是最根本的一问。WebSocket的优势在于低延迟的双向实时通信。如果“长文本”的发送是低频的、非实时的，或者对实时性要求不严格，那么使用WebSocket可能不是最佳选择。

替代方案对比：

建议：

• 实时聊天中的长消息： 使用WebSocket分片。用户期望即时反馈。
• 提交大型表单或配置： 考虑改用HTTP POST（multipart/form-data）。更简单，更利于利用浏览器的上传进度API，也更容易做重试。
• 上传日志文件或文档： 使用专门的文件上传接口（HTTP），支持分块和断点续传。
• 服务器向多个客户端推送大型报表： 可以考虑先用WebSocket通知“报表已生成，可通过链接下载”，然后客户端通过HTTP去下载文件。或者将报表生成任务放入消息队列，由后端服务异步处理并存储，再通知客户端获取。

混合架构： 一个常见的模式是“信令+数据通道”。WebSocket仅用于传输轻量的控制信令（如“开始传输”、“确认收到第N片”、“暂停”），而实际的大块数据通过HTTP或专门的二进制通道（如WebRTC的数据通道）传输。这保持了实时控制的灵活性，又规避了WebSocket传输大数据的局限性。

6. 实战排查与性能调优记录

即使方案设计完美，线上环境依然可能出问题。这里记录几个实战中遇到的典型问题和调优点。

6.1 连接不稳定下的分片处理

在网络抖动或移动端环境下，连接可能中断。如果长文本分片发送到一半连接断开，如何处理？

解决方案：

1. 会话粘性： 确保重连后，客户端使用相同的messageId继续发送剩余分片。服务端组装器需要持久化（如存到Redis），并设置较长的超时时间。
2. 服务端主动查询： 客户端重连后，主动向服务端上报未完成的消息ID。服务端检查组装状态，并告知客户端缺失的分片索引，客户端进行补发。
3. 简化策略-客户端重发： 对于非严格顺序的业务，客户端在检测到连接恢复后，简单地从第一个分片开始重新发送整个消息。服务端收到重复分片时，根据messageId和index去重。这增加了网络开销，但逻辑简单。

6.2 内存泄漏与组装器管理

如前所述，静态Map是内存泄漏的重灾区。

优化实践：

@Component public class FragmentManager { private final Cache<String, MessageAssembler> assemblerCache; public FragmentManager() { this.assemblerCache = Caffeine.newBuilder() .maximumSize(10000) // 最大缓存1万个组装中的消息 .expireAfterWrite(5, TimeUnit.MINUTES) // 5分钟未完成则过期 .removalListener((key, assembler, cause) -> { if (assembler != null) { ((MessageAssembler)assembler).cleanup(); // 清理资源 } }) .build(); } public MessageAssembler getOrCreateAssembler(String messageId, int total, String type) { // computeIfAbsent 的缓存安全版本 return assemblerCache.get(messageId, k -> new MessageAssembler(total, type)); } public void removeAssembler(String messageId) { assemblerCache.invalidate(messageId); } }

使用Caffeine或Guava Cache替代简单的ConcurrentHashMap，自动处理过期和大小限制，是生产环境的必备。

6.3 监控与度量

你需要知道系统的健康状况。

• 关键指标：
  • websocket_message_fragment_received_total： 收到的分片总数。
  • websocket_message_assembled_total： 成功组装的消息总数。
  • websocket_assembler_cache_size： 当前缓存中的组装器数量。
  • websocket_message_duration_seconds： 从收到第一个分片到组装完成的时间分布。
  • websocket_message_size_bytes： 组装完成的消息大小分布。
• 日志记录： 为重要的操作（如开始组装、组装完成、组装超时）记录结构化日志，便于问题追踪。
• 告警： 为组装器缓存数量设置告警阈值（如超过8000），为平均组装时间设置告警（如超过10秒）。

6.4 压力测试与边界值测试

在上线前，必须进行全面的测试。

1. 正常功能测试： 发送刚好等于、略小于、略大于分片大小的消息。
2. 压力测试：
   • 并发长消息： 模拟100个客户端同时发送1MB的长文本。
   • 持续流： 一个客户端持续快速地发送分片消息，测试服务端的处理速度和内存增长。
   • 乱序测试： 虽然WebSocket保证顺序，但可以模拟客户端故意乱序发送分片（需要定制客户端），测试组装逻辑的健壮性。
3. 异常测试：
   • 中途断开： 发送部分分片后，主动断开客户端连接，观察服务端资源清理情况。
   • 重复分片： 客户端重复发送同一分片。
   • 错误分片索引： 发送index为负数或大于total的分片。
   • ID冲突： 两个客户端使用相同的messageId（概率极低但需考虑）。

通过以上从问题根因到架构选型的全面剖析，你会发现，“Java实现WebSocket发送长文本”远不止是一个配置参数问题。它是一个涉及协议理解、服务器特性、应用设计、资源管理和异常处理的综合性课题。最稳妥的路径是：首先根据业务体量合理配置服务器缓冲区作为第一道防线；其次，对于可能超出阈值或追求极高可靠性的场景，务必在应用层实现分片协议；最后，始终审视业务场景，选择最合适的通信方式，不要试图用WebSocket这把“锤子”去敲所有的“钉子”。