← Concepts

阅读中文版本

Asynchronous I/O

Asynchronous IO starts an operation and continues without blocking, notifying completion later, which lets one thread service many sockets or file operations.

concurrency

Definition

Asynchronous input and output is a model in which a program initiates an operation and receives a completion indication later, instead of blocking the calling thread until the operation finishes.

Context and scope

It is the basis of high-throughput servers, event loops, and runtimes that must juggle thousands of concurrent network connections.

Common misconceptions

  • asynchronous IO is the same as non-blocking IO
  • asynchronous operations necessarily run on other threads

Anti-patterns

  • calling synchronous file APIs inside an async handler
  • assuming all filesystems support true asynchronous IO equally

Related concepts

Related examples

Authoritative source

https://en.wikipedia.org/wiki/Asynchronous_I/O

Definition

Asynchronous input and output is a model in which a program initiates an operation and receives a completion indication later, instead of blocking the calling thread until the operation finishes.

It is the basis of high-throughput servers, event loops, and runtimes that must juggle thousands of concurrent network connections. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

Non-blocking IO returns immediately when an operation would block and the program polls readiness, whereas asynchronous IO hands the whole operation to the kernel or runtime and reports completion.

Completion can arrive via callbacks, futures, or an event loop, and the thread that initiated the operation is free in the meantime.

Trade-offs and alternatives

Mixing synchronous calls into an asynchronous pipeline defeats the model, because one blocking call stalls every task scheduled on that event loop. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that asynchronous IO is the same as non-blocking IO. Another is that asynchronous operations necessarily run on other threads. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to calling synchronous file APIs inside an async handler and to assuming all filesystems support true asynchronous IO equally. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Goroutine and Task Leaks, I/O Multiplexing with epoll and kqueue, Atomic Operations.