<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
      <title>bigfish的网络博客 - 操作系统</title>
      <link>https://blog.bigfisharc.cn</link>
      <description>记录技术和生活</description>
      <generator>Zola</generator>
      <language>zh</language>
      <atom:link href="https://blog.bigfisharc.cn/tags/cao-zuo-xi-tong/rss.xml" rel="self" type="application/rss+xml"/>
      <lastBuildDate>Wed, 07 Oct 2026 15:48:15 +0800</lastBuildDate>
      <item>
          <title>为什么 Rust 的无栈协程是异步 I/O 的技术最优解？</title>
          <pubDate>Wed, 07 Oct 2026 15:48:15 +0800</pubDate>
          <author>bigfish</author>
          <link>https://blog.bigfisharc.cn/blog/thread-goroutine-rust-stackless-design/</link>
          <guid>https://blog.bigfisharc.cn/blog/thread-goroutine-rust-stackless-design/</guid>
          <description xml:base="https://blog.bigfisharc.cn/blog/thread-goroutine-rust-stackless-design/">&lt;p&gt;Go 可以在普通调用链深处挂起 goroutine，让线程去处理其他工作。Rust 为什么没有采用同样的方式，却要求开发者显式写出 &lt;code&gt;async/await&lt;/code&gt;，还要面对 Future、Pin 和执行器？&lt;/p&gt;
&lt;p&gt;本文要论证的是：&lt;strong&gt;在大量任务都等待网络的异步 I/O 场景中，Rust 的无栈协程可以称为技术最优解。&lt;/strong&gt; 这里的“最优”不是跑分意义上的全面胜出，而是指它同时解决了三个核心问题：等待中的任务不必各自占用一份可挂起的协程栈，异步操作可以组合，执行路径又能由编译器直接生成状态机。&lt;/p&gt;
&lt;p&gt;这里的“技术最优解”有明确范围：比较的是等待任务的内存占用、可组合性、执行效率、运行时耦合和资源边界。无栈协程省掉的是每个等待任务的专属协程栈，不是 Future 状态、连接和缓冲区本身；它也不是宣称所有负载下都最快。CPU 密集计算、长时间阻塞调用和需要透明暂停的场景，仍然可能适合线程或有栈协程。后文会先解释这些方案分别保存什么，再说明为什么这组取舍在异步 I/O 中占优。&lt;/p&gt;</description>
      </item>
    </channel>
</rss>
