当前位置: 首页 > 知识库问答 >
问题:

反应式非阻塞I/O调用web套接字会不会堆栈溢出?

欧阳高昂
2023-03-14
thread: {
        Obj request;
        // There are at most several socket for threads num
        Obj response = syncClient.blockingWebRequest(request);
        // ...
        logicHandle();
        // ...
        return response;
    }

但在被动非阻塞I/O中,我们会在异步中调用socket,因此如果请求太多,当前会调用大量的web socket。OS套接字堆栈能hold住吗?缓冲区怎么样?

eventLoop: {
        Mono request;
        // Non-blocking IO continuously receives and establishes socket
        Mono response = asyncClient.nonBlockingWebRequest(request);
        response.onSubscribe(()->{
            // ...
            logicHandle();
            // ...
        });
        return response;
    }

例如,同时建立数百万套接字连接。

  • 套接字占用10s。
  • CPU计算1ms.

是否会在第一个插座返回之前进行10,000个插座连接?

eventLoop: {
        // eventLoop handles one in 1ms
        Mono request;
        // Non-blocking IO continuously receives and establishes socket
        Mono response = asyncClient.nonBlockingWebRequest(request);
        // This will callback after 10s
        response.onSubscribe(()->{
            // ...
            logicHandle();
            // ...
        });
        // eventLoop continue
        return response;
    }

非常感谢你回答我的问题!

共有1个答案

竺展
2023-03-14

毫无疑问,如果速率很高,最终缓冲区会满。

缓冲区的溢出会通过TCP从接收端反馈到发送端。

背压是一种解决方法。

 类似资料:
  • 问题内容: 非阻塞TCP / IP S和在NIO帮我处理与小数目的线程许多TCP / IP连接。但是UDP 呢?(我必须承认我对UDP不太熟悉。) 即使UDP发送操作未在阻止模式下运行,它似乎也不会阻止。确实存在因拥堵或类似原因导致阻塞的情况吗?我真的很好奇,是否存在这样的情况以及生产环境中可能存在的情况。 如果实际上并没有阻塞,并且我不打算使用已连接并仅绑定到一个端口,那么使用非阻塞模式和and

  • 现在我们知道如何在一个指定I/O调度器上来调度一个任务,我们可以修改storeBitmap()函数并再次检查StrictMode的不合规做法。为了这个例子,我们可以在新的blockingStoreBitmap()函数中重排代码。 private static void blockingStoreBitmap(Context context, Bitmap bitmap, String filena

  • 实时的web特性通常需要为每个用户一个大部分时间都处于空闲的长连接. 在传统的同步web服务器中,这意味着需要给每个用户分配一个专用的线程,这样的开销是十分巨大的. 为了减小对于并发连接需要的开销,Tornado使用了一种单线程事件循环的方式. 这意味着所有应用程序代码都应该是异步和非阻塞的,因为在同一时刻只有一个操作是有效的. 异步和非阻塞这两个属于联系十分紧密而且通常交换使用,但是它们并不完全

  • 我正在使用Spring云平台开发微服务,其中service1调用多个其他微服务,例如service2、service3、Service4等。这些服务可以并行调用,service1将聚合结果。我能用春云伪装吗(http://cloud.spring.io/spring-cloud-static/Dalston.SR1/#spring-cloud Faign)生成rest客户端并异步调用服务,还是应该

  • 问题内容: 当我直接使用(没有诸如Scanner之类的界面)接收数据时,它不会阻塞。但是,当我尝试使用Scanner时(类似于我们从接收字符串的方式),它确实可以。我想知道这样做的原因,以及所连接的Socket提供给您的InputStream与in的不同之处。 用于测试的客户端(用于两个服务器) 挂起的代码: 不阻塞的代码: 问题答案: (我认为您已经知道了这一点,但是…) 该方法返回当前行的其余

  • 问题内容: 为什么有人会喜欢阻止写而不是非阻止写?我的理解是,仅当您想确保写方法返回后,另一端获得了TCP数据包时,才希望阻止写操作,但是我什至不知道这是可能的。您将必须刷新,而刷新则必须刷新 底层操作系统的写套接字缓冲区 。那么,无阻塞套接字写是否有任何缺点?就性能而言,拥有较大的底层写套接字是否会缓冲一个不好的主意?我的理解是,底层套接字写缓冲区越小,当底层套接字缓冲区已满且isWritabl