Great question! 首先明确说：OkHttp完全可以支持数千个WebSocket连接做负载测试，但你碰到的4000个连接后触发的OOM错误，本质上不是OkHttp的限制，而是系统和JVM层面的资源瓶颈。

先搞懂错误根源 #

你看到的java.lang.OutOfMemoryError: unable to create a native thread，核心原因有两个：

1. 操作系统线程数限制：每个WebSocket连接在默认配置下，OkHttp会为其分配关联的线程（或占用线程池中的线程），而每个操作系统对单个进程能创建的线程数有严格上限（比如Linux默认单进程线程数大概在4000-10000之间，Windows也有类似限制）。当你开到4000个连接时，已经触达了这个上限。
2. 线程栈内存耗尽：每个Java线程默认的栈大小是1MB左右，4000个线程光栈内存就占了4GB，很容易把你的JVM内存吃满，导致无法创建新线程。

解决方案分三步走 #

1. 优化OkHttp的配置，减少线程开销

首先要避免一个常见错误：不要为每个WebSocket连接创建新的OkHttpClient实例！每个OkHttpClient都会初始化自己的线程池和连接池，多个实例会导致线程数爆炸，一定要全局复用同一个OkHttpClient对象。

然后调整以下配置：

• 自定义Dispatcher，合理设置线程池参数：可以通过Dispatcher.setMaxRequests()和Dispatcher.setMaxRequestsPerHost()控制并发请求数，但更关键的是配置OkHttpClient的线程池，用更小的核心线程数——因为OkHttp的WebSocket基于NIO，本来就可以复用线程处理多个连接。
• 配置连接池：通过new ConnectionPool(50, 5, TimeUnit.MINUTES)设置合适的空闲连接数和存活时间，避免连接资源浪费。
• 避免在WebSocket回调里做阻塞操作：比如onMessage()里不要同步执行耗时任务，否则会占用线程，导致需要创建更多线程来处理新连接。

2. 调整系统和JVM的资源限制

这是突破4000连接上限的核心：

• Linux系统：
  • 修改/etc/security/limits.conf，添加/修改：

    your_username soft nproc 10000
    your_username hard nproc 10000
    

  • 临时调整内核参数（重启后失效，要永久生效需修改sysctl.conf）：

    echo 20000 > /proc/sys/kernel/threads-max
    echo 65530 > /proc/sys/vm/max_map_count
    

  • 调整JVM线程栈大小：启动时添加-Xss256k，把每个线程的栈从默认1MB降到256k，这样4000个线程只需要1GB栈内存，能大幅减少内存占用。
• Windows系统：
  • 通过组策略或注册表调整进程的线程数限制（具体可搜索“Windows 进程线程数限制修改”）。
  • 同样在JVM启动参数里加-Xss256k减少栈内存开销，同时调大堆内存比如-Xmx8G。

3. 考虑换用专门的负载测试工具

如果你的核心需求是做负载测试，而不是用OkHttp实现测试逻辑，那更推荐用专门的工具：比如k6（支持WebSocket脚本）、Apache JMeter（有WebSocket插件），这些工具本身就是为高并发场景设计的，内部做了大量资源优化，比如复用线程、减少内存开销，比自己用OkHttp写代码更容易突破上万连接的限制，而且自带监控和报告功能，效率更高。

额外注意点 #

• 给测试机器留足够内存：除了线程栈，每个WebSocket连接还有OkHttp内部的对象开销，所以JVM堆内存要调够，比如-Xmx8G甚至更高。
• 监控系统指标：用top（Linux）或任务管理器（Windows）实时看线程数、内存使用率，确认是线程数触顶还是内存不足。
• 减少不必要的对象创建：在WebSocket回调里尽量复用对象，避免频繁创建新对象导致GC压力过大，间接引发内存问题。

总结一下：只要调整好系统资源限制和OkHttp的配置，用OkHttp建立数千个WebSocket连接完全可行，但如果是专业负载测试，专门的工具会更省心高效。

内容的提问来源于stack exchange，提问作者user2419598