libuv核心概念
在理解和使用 libuv 的过程中，掌握其核心概念至关重要。libuv 通过事件驱动模型和异步 I/O 为应用程序提供了高效的并发能力。以下是 libuv 的四个核心概念。
事件循环（Event Loop）
事件循环是 libuv 的核心驱动机制，负责协调和管理所有的异步操作。它采用单线程模型，利用一个多阶段的循环机制来处理 I/O 事件、定时器、回调等各种并发任务。通过事件循环，libuv 能够在不阻塞主线程的情况下，处理大量的异步事件，从而提升系统的并发性能和响应速度。
libuv 的事件循环分为多个主要阶段，每个阶段都有独特的职责，确保各种异步任务按需调度和执行：
- 定时器阶段：负责处理定时事件。这一阶段会检查并执行已经超时的定时器回调函数，用于实现定时任务的功能，例如超时检查、定时事件触发等。
- I/O 阶段：这是事件循环的核心，主要用于监听和处理网络 I/O、文件 I/O 等准备就绪的事件。libuv 通过非阻塞 I/O 和操作系统的底层接口，如 epoll、kqueue 等，高效地管理网络连接、文件读写等 I/O 操作，使得应用能够快速响应 I/O 事件。
- 空闲和检查阶段：在此阶段中，事件循环会处理一些优先级较低的任务，例如非关键的状态更新、缓存清理等。这类任务通常不会直接影响系统的实时性，但通过合理安排可以提高系统的整体效率。
- 关闭阶段：在事件循环的尾部，关闭阶段会进行资源释放和清理操作。例如，在关闭某个文件句柄或网络连接时，会调用相应的清理回调，确保资源被安全地释放。
通过多阶段的精细化设计，libuv 的事件循环能够实现高效的异步操作管理。在单线程模式下，通过合理安排不同任务的执行顺序和时间点，libuv 将异步任务分发至合适的阶段，确保高并发性能的同时，避免线程切换和锁机制带来的额外开销。这一设计不仅是 libuv 的核心优势，也是其广泛应用于高性能服务器、微服务和实时应用的关键所在。
定时器阶段
在 libuv 的事件循环中，定时器阶段主要负责管理和执行已超时的定时器回调。这个阶段确保定时任务按时触发，是实现诸如超时控制、周期性任务的关键组成部分。
libuv 使用一个小顶堆（min-heap）数据结构来管理所有活跃的定时器，能够高效地查找并处理最早触发的定时器事件。这种结构的优点在于，只需对堆顶进行检查即可确认当前是否有已到时间的定时器要执行，进而实现高效的定时事件管理。
以下是定时器处理的主要过程：
void uv__run_timers(uv_loop_t* loop) {
struct heap_node* heap_node;
uv_timer_t* handle;
struct uv__queue* queue_node;
struct uv__queue ready_queue;
uv__queue_init(&ready_queue);
// 把所有已到超时时间的定时器全部取出放到ready_queue队列里
for (;;) {
heap_node = heap_min(timer_heap(loop));
if (heap_node == NULL)
break;
handle = container_of(heap_node, uv_timer_t, node.heap);
// 当定时器超时时间截<=当前loop的时间截则认为超时时间已到，否则则认为未到超时时间
if (handle->timeout > loop->time) // 堆顶的还未到超时间，则说明所有的定时器都未到超时时间，直接退出循环
break;
// 从队列中删除
uv_timer_stop(handle);
uv__queue_insert_tail(&ready_queue, &handle->node.queue);
}
// 调用所有定时器的callback
while (!uv__queue_empty(&ready_queue)) {
queue_node = uv__queue_head(&ready_queue);
uv__queue_remove(queue_node);
uv__queue_init(queue_node);
handle = container_of(queue_node, uv_timer_t, node.queue);
// 如果没有结束的定时器需要再次加入原管理器队列
uv_timer_again(handle);
handle->timer_cb(handle);
}
}定时器阶段的主要过程
- 定时器检查：在每次事件循环开始时，libuv 检查当前时间，并与堆顶的定时器进行比较。若当前时间已超出堆顶定时器的设定时间，说明该定时器需要执行。
- 在通过uv_timer_start创建一个定时器uv_timer_t时，会给ui_timer_t.timeout进行赋值，确定这个定时器到期的时间截，这个时间截是基于loop->time得到的。定时器创建成功后加入到最小堆中。
int uv_timer_start(uv_timer_t* handle,
uv_timer_cb cb,
uint64_t timeout,
uint64_t repeat) {
uint64_t clamped_timeout;
if (uv__is_closing(handle) || cb == NULL)
return UV_EINVAL;
uv_timer_stop(handle);
// handle->loop->time为定时器所属loop的当前时间截，加上超时时间间隔则为下一次超时时间截
// 超时时间截是一个绝对值，不是相对量
clamped_timeout = handle->loop->time + timeout;
if (clamped_timeout < timeout)
clamped_timeout = (uint64_t) -1;
handle->timer_cb = cb;
handle->timeout = clamped_timeout;
handle->repeat = repeat;
/* start_id is the second index to be compared in timer_less_than() */
handle->start_id = handle->loop->timer_counter++;
// 加入到最小堆，根据handle->timeout进行排序，最先超时的再堆顶
heap_insert(timer_heap(handle->loop),
(struct heap_node*) &handle->node.heap,
timer_less_than);
uv__handle_start(handle);
return 0;
}- 触发与执行回调：当定时器到达设定的触发时间，libuv 将其从堆顶移出并执行与其关联的回调函数。这样可确保任务在规定时间内被触发。
- 重新排列堆：执行完回调后，libuv 会重新排列堆结构，确保下一个最早触发的定时器位于堆顶，方便下次循环快速访问。
定时器的周期性与单次执行
- 单次定时器：可以通过设置定时器的触发时间，使其在到达时间后只执行一次。
- 周期性定时器：支持以固定的间隔重复触发，适用于需要定期执行的任务。libuv 会在每次触发周期性定时器后，自动重新设定下一次触发时间，并将其重新插入堆中。
libuv 定时器的性能优势
libuv 的定时器实现适用于大量定时器任务场景，不同于线性扫描或简单队列管理定时器的方式，堆结构在保持灵活性的同时，确保了定时器的添加和触发都具备较高性能。
.2I/O 阶段
在 libuv 的 I/O 阶段，主要任务是通过系统底层提供的多路复用机制（如 epoll、kqueue、IOCP 等）来监听和处理所有注册的文件描述符的事件。该阶段在 uv__io_poll 函数中实现，是 libuv 事件循环的核心部分。
void uv__io_poll(uv_loop_t* loop, int timeout) {
......
assert(timeout >= -1);
base = loop->time;
count = ; /* Benchmarks suggest this gives the best throughput. */
real_timeout = timeout;
if (lfields->flags & UV_METRICS_IDLE_TIME) {
reset_timeout = 1;
user_timeout = timeout;
timeout = 0;
} else {
reset_timeout = 0;
user_timeout = 0;
}
epollfd = loop->backend_fd;
memset(&e, 0, sizeof(e));
// 将需要监听的事件加入或者更新到epoll实例中
// 外部通过 uv__io_t 对象来存储数据，libuv 定义的统一的事件对象
while (!uv__queue_empty(&loop->watcher_queue)) {
q = uv__queue_head(&loop->watcher_queue);
w = uv__queue_data(q, uv__io_t, watcher_queue);
uv__queue_remove(q);
uv__queue_init(q);
op = EPOLL_CTL_MOD;
if (w->events == 0)
op = EPOLL_CTL_ADD;
w->events = w->pevents;
e.events = w->pevents;
e.data.fd = w->fd;
fd = w->fd;
if (ctl->ringfd != -1) {
uv__epoll_ctl_prep(epollfd, ctl, &prep, op, fd, &e);
continue;
}
if (!epoll_ctl(epollfd, op, fd, &e)) // 注册到epoll
continue;
assert(op == EPOLL_CTL_ADD);
assert(errno == EEXIST);
/* File descriptor that's been watched before, update event mask. */
if (epoll_ctl(epollfd, EPOLL_CTL_MOD, fd, &e))
abort();
}
inv.events = events;
inv.prep = &prep;
inv.nfds = -1;
// 进入等待事件的循环，当时间到期后则退出等待，时长为timeout
for (;;) {
if (loop->nfds == 0)
if (iou->in_flight == 0)
break;
/* All event mask mutations should be visible to the kernel before
* we enter epoll_pwait().
*/
if (ctl->ringfd != -1)
while (*ctl->sqhead != *ctl->sqtail)
uv__epoll_ctl_flush(epollfd, ctl, &prep);
/* Only need to set the provider_entry_time if timeout != 0. The function
* will return early if the loop isn't configured with UV_METRICS_IDLE_TIME.
*/
if (timeout != 0)
uv__metrics_set_provider_entry_time(loop);
/* Store the current timeout in a location that's globally accessible so
* other locations like uv__work_done() can determine whether the queue
* of events in the callback were waiting when poll was called.
*/
lfields->current_timeout = timeout;
// 这里用epoll_pwait来实现等待事件
nfds = epoll_pwait(epollfd, events, ARRAY_SIZE(events), timeout, sigmask);
/* Update loop->time unconditionally. It's tempting to skip the update when
* timeout == 0 (i.e. non-blocking poll) but there is no guarantee that the
* operating system didn't reschedule our process while in the syscall.
*/
SAVE_ERRNO(uv__update_time(loop));
if (nfds == -1)
assert(errno == EINTR);
else if (nfds == 0)
/* Unlimited timeout should only return with events or signal. */
assert(timeout != -1);
if (nfds == 0 || nfds == -1) {
if (reset_timeout != 0) {
timeout = user_timeout;
reset_timeout = 0;
} else if (nfds == 0) {
return;
}
/* Interrupted by a signal. Update timeout and poll again. */
goto update_timeout;
}
have_iou_events = 0;
have_signals = 0;
nevents = 0;
inv.nfds = nfds;
lfields->inv = &inv;
// 处理I/O事件
for (i = 0; i < nfds; i++) {
pe = events + i;
fd = pe->data.fd;
/* Skip invalidated events, see uv__platform_invalidate_fd */
if (fd == -1)
continue;
if (fd == iou->ringfd) {
uv__poll_io_uring(loop, iou);
have_iou_events = 1;
continue;
}
assert(fd >= 0);
assert((unsigned) fd < loop->nwatchers);
w = loop->watchers[fd];
if (w == NULL) {
/* File descriptor that we've stopped watching, disarm it.
*
* Ignore all errors because we may be racing with another thread
* when the file descriptor is closed.
*
* Perform EPOLL_CTL_DEL immediately instead of going through
* io_uring's submit queue, otherwise the file descriptor may
* be closed by the time the kernel starts the operation.
*/
epoll_ctl(epollfd, EPOLL_CTL_DEL, fd, pe);
continue;
}
/* Give users only events they're interested in. Prevents spurious
* callbacks when previous callback invocation in this loop has stopped
* the current watcher. Also, filters out events that users has not
* requested us to watch.
*/
pe->events &= w->pevents | POLLERR | POLLHUP;
/* Work around an epoll quirk where it sometimes reports just the
* EPOLLERR or EPOLLHUP event. In order to force the event loop to
* move forward, we merge in the read/write events that the watcher
* is interested in; uv__read() and uv__write() will then deal with
* the error or hangup in the usual fashion.
*
* Note to self: happens when epoll reports EPOLLIN|EPOLLHUP, the user
* reads the available data, calls uv_read_stop(), then sometime later
* calls uv_read_start() again. By then, libuv has forgotten about the
* hangup and the kernel won't report EPOLLIN again because there's
* nothing left to read. If anything, libuv is to blame here. The
* current hack is just a quick bandaid; to properly fix it, libuv
* needs to remember the error/hangup event. We should get that for
* free when we switch over to edge-triggered I/O.
*/
if (pe->events == POLLERR || pe->events == POLLHUP)
pe->events |=
w->pevents & (POLLIN | POLLOUT | UV__POLLRDHUP | UV__POLLPRI);
if (pe->events != 0) {
/* Run signal watchers last. This also affects child process watchers
* because those are implemented in terms of signal watchers.
*/
if (w == &loop->signal_io_watcher) {
have_signals = 1;
} else {
uv__metrics_update_idle_time(loop);
w->cb(loop, w, pe->events); // 事件的回调函数调用
}
nevents++;
}
}
uv__metrics_inc_events(loop, nevents);
if (reset_timeout != 0) {
timeout = user_timeout;
reset_timeout = 0;
uv__metrics_inc_events_waiting(loop, nevents);
}
if (have_signals != 0) {
uv__metrics_update_idle_time(loop);
loop->signal_io_watcher.cb(loop, &loop->signal_io_watcher, POLLIN);
}
lfields->inv = NULL;
if (have_iou_events != 0)
break; /* Event loop should cycle now so don't poll again. */
if (have_signals != 0)
break; /* Event loop should cycle now so don't poll again. */
if (nevents != 0) {
if (nfds == ARRAY_SIZE(events) && --count != 0) {
/* Poll for more events but don't block this time. */
timeout = 0;
continue;
}
break;
}
update_timeout:
if (timeout == 0)
break;
if (timeout == -1)
continue;
assert(timeout > 0);
real_timeout -= (loop->time - base);
if (real_timeout <= 0)
break;
timeout = real_timeout;
}
if (ctl->ringfd != -1)
while (*ctl->sqhead != *ctl->sqtail)
uv__epoll_ctl_flush(epollfd, ctl, &prep);
}以下是该阶段的主要内容及过程：
1. 文件描述符的管理与注册
libuv 使用 uv__io_t 结构体来管理和存储每个文件描述符及其相关事件。每个 uv__io_t 对象都与回调函数关联，以在对应的事件发生时调用。
2. 使用多路复用机制进行事件监听
在 I/O 阶段，libuv 调用平台特定的函数（如 Linux 上的 epoll_wait、BSD 上的 kevent）来等待文件描述符上的事件。调用的核心逻辑如下：
- 注册监听：在事件循环运行时，libuv 将所有需要监控的文件描述符和事件类型通过 epoll_ctl 注册到 epoll 实例中。
- 等待事件：epoll_pwait 被调用以等待这些事件。它根据传入的 timeout 参数决定是否阻塞以及阻塞时间。
3. 事件处理
当 epoll_wait 返回时，libuv 会遍历返回的事件列表，依次处理每个事件。每个文件描述符触发的事件会调用其对应的回调函数。过程如下：
- 事件过滤：在处理事件时，libuv 检查事件类型，如 POLLIN（可读）、POLLOUT（可写）、POLLERR（错误）等。
- 回调执行：调用 uv__io_t 结构体中存储的回调函数来处理实际的 I/O 操作。
4. 特殊事件的处理
libuv 还会处理一些特殊情况，如信号中断（EINTR）和特定事件的合并（如 POLLERR 与 POLLHUP），以确保不会因为意外情况中断事件循环。
5. 多次轮询与非阻塞处理
当 epoll_pwait 返回的事件数量达到数组上限时，libuv 会继续循环并进行非阻塞的再次轮询，以避免漏掉事件。这样做确保了高并发情况下的事件处理效率。
总结
libuv 的 I/O 阶段通过底层的多路复用机制实现高效的 I/O 事件监控和处理。它以非阻塞的方式处理大量事件，确保了高性能和响应速度。
空闲和检查阶段
在 libuv 的事件循环中，空闲（idle）阶段和检查（check）阶段是重要的组成部分，负责处理应用程序逻辑中的不同类型的任务。以下是这两个阶段的详细说明：
- 空闲（Idle）阶段
主要内容：
空闲阶段专门用于执行非关键路径的回调函数。这些函数在事件循环中没有其他 I/O 操作待处理时执行。空闲阶段的主要目的是在没有其他优先级更高的任务时，执行一些可以推迟处理的操作，比如长时间的计算、状态监控、或者后台任务。
过程：
- 注册空闲句柄：通过 uv_idle_t 结构体注册空闲回调。
- 调用 uv_idle_start：函数 uv_idle_start 被调用以启动空闲处理，并传入回调函数。
- 事件循环执行：在每次事件循环中，如果没有 I/O 或其他优先级更高的任务，libuv 会执行空闲阶段的回调。
- 停止空闲阶段：可以通过 uv_idle_stop 停止空闲处理，防止回调被继续执行。
- 检查（Check）阶段
主要内容：
检查阶段的主要作用是确保在进入下一个 I/O 阶段之前执行回调。这个阶段的回调是在 I/O 阶段后触发的，用来在即将进入休眠或等待新事件之前执行一些必要的任务。通常用于在 I/O 处理完成之后进行清理或准备下一步操作。
过程：
- 注册检查句柄：通过 uv_check_t 结构体注册检查回调。
- 调用 uv_check_start：函数 uv_check_start 被调用来启动检查回调。
- 回调执行：在每个事件循环中，当所有 I/O 操作已完成时，libuv 调用该阶段的回调函数。
- 检查阶段完成：通常用于在进入休眠或阻塞前的最后检查，比如进行日志记录或数据更新。
流程总结：
- 空闲阶段：在没有其他待处理事件时执行，适用于后台任务和非实时操作。
- 检查阶段：在 I/O 完成后执行，是进入下一次等待或休眠前的最后一步，适合用来做最终检查或准备工作。
通过这些阶段的执行，libuv 能够确保应用程序的不同任务得到适当的调度和执行。
关闭阶段
在 libuv 的主事件循环中，关闭阶段 是整个流程的最后一个步骤，其作用是确保所有已经被请求关闭的句柄（handles）被正确处理，释放相关资源并调用关闭回调函数。
关闭阶段的作用：
- 资源释放：关闭阶段的主要作用是确保所有已被标记为关闭的句柄在程序结束前都被正确销毁，以释放系统资源。
- 调用关闭回调：libuv 在关闭阶段会调用用户注册的关闭回调函数，如 uv_close() 中提供的回调。这允许开发者在句柄关闭后进行清理操作或其他善后处理。
- 确保事件循环退出：关闭阶段是事件循环退出的最后保障。在这个阶段结束之后，如果所有资源都已释放，libuv 可以安全地结束事件循环。
流程解析：
关闭阶段的主要逻辑涉及遍历已被标记为关闭的句柄并调用其回调函数。以下是关闭阶段的关键流程：
- 扫描和遍历关闭队列：
- libuv 会遍历存储在事件循环中 closing_handles 队列中的句柄。
- 它会检查每个句柄是否已被标记为关闭，并准备进行资源释放。
- 调用关闭回调函数：
- 对每个已标记为关闭的句柄，libuv 调用关联的关闭回调函数（如果有），这让用户可以在句柄真正销毁之前执行清理或日志记录等操作。
- 从事件循环中移除句柄：
- 在回调执行完毕后，libuv 将该句柄从事件循环中移除，标记为不可再用状态。
- 检查是否有剩余未关闭的活动句柄：
- 如果没有其他未关闭的句柄，libuv 会退出事件循环，标志程序运行结束。如果还有未处理的句柄，循环会继续运行直到它们全部关闭。
static void uv__finish_close(uv_handle_t* handle) {
uv_signal_t* sh;
/* Note: while the handle is in the UV_HANDLE_CLOSING state now, it's still
* possible for it to be active in the sense that uv__is_active() returns
* true.
*
* A good example is when the user calls uv_shutdown(), immediately followed
* by uv_close(). The handle is considered active at this point because the
* completion of the shutdown req is still pending.
*/
assert(handle->flags & UV_HANDLE_CLOSING);
assert(!(handle->flags & UV_HANDLE_CLOSED));
handle->flags |= UV_HANDLE_CLOSED;
switch (handle->type) {
case UV_PREPARE:
case UV_CHECK:
case UV_IDLE:
case UV_ASYNC:
case UV_TIMER:
case UV_PROCESS:
case UV_FS_EVENT:
case UV_FS_POLL:
case UV_POLL:
break;
// 检查是否有未处理的信号事件。如果有，暂时不调用关闭回调，将句柄重新插入关闭队列以处理剩余的事件。
case UV_SIGNAL:
/* If there are any caught signals "trapped" in the signal pipe,
* we can't call the close callback yet. Reinserting the handle
* into the closing queue makes the event loop spin but that's
* okay because we only need to deliver the pending events.
*/
sh = (uv_signal_t*) handle;
if (sh->caught_signals > sh->dispatched_signals) {
handle->flags ^= UV_HANDLE_CLOSED;
uv__make_close_pending(handle); /* Back into the queue. */
return;
}
break;
case UV_NAMED_PIPE:
case UV_TCP:
case UV_TTY:
uv__stream_destroy((uv_stream_t*)handle);
break;
case UV_UDP:
uv__udp_finish_close((uv_udp_t*)handle);
break;
default:
assert(0);
break;
}
uv__handle_unref(handle);
uv__queue_remove(&handle->handle_queue);
// 进行关闭回调
if (handle->close_cb) {
handle->close_cb(handle);
}
}重要提示：
- 非立即关闭：即使调用了 uv_close()，句柄并不会立即被销毁。它会被标记并在关闭阶段处理。
- 不可逆：一旦句柄被加入关闭队列，后续任何尝试访问或使用都会引发不可预期的行为。
这个阶段的存在确保了 libuv 能够安全、稳定地清理资源，使得事件循环在退出时没有残留的资源问题。
句柄与请求
libuv 是一个跨平台的异步 I/O 库，它通过句柄（Handle）和请求（Request）这两大核心数据结构来组织和管理各种异步操作。以下是对这两个概念的更详细和完整的阐述：
句柄（Handle）
句柄是 libuv 中对某种特定资源的抽象，包括网络套接字、计时器、文件系统事件等。每种资源在 libuv 中都由一个对应的句柄结构体表示，例如：
- uv_tcp_t：用于 TCP 网络连接。
- uv_udp_t：用于 UDP 数据报。
- uv_timer_t：用于定时器功能。
- uv_fs_event_t：用于文件系统事件监控。
这些句柄继承自一个基础结构 uv_handle_t，它包含了用于管理生命周期的通用字段和标志。句柄的生命周期由 libuv 的事件循环（uv_loop_t）管理，libuv 会在事件循环中跟踪各个句柄的状态并调用回调函数来响应事件。
句柄的特性和操作
- 引用计数和状态管理：libuv 使用引用计数来决定句柄是否需要继续活跃，只有当引用计数为零时，libuv 才会认为该句柄不再需要维护。
- 回调函数：句柄与回调机制紧密结合，每个句柄通常需要一个或多个回调函数来响应事件。例如，uv_tcp_t 会使用回调来处理新连接或数据读取事件。
- 句柄的关闭：调用 uv_close() 函数会标记句柄为即将关闭，并确保在事件循环的关闭阶段完成其资源清理。
请求（Request）
请求表示在句柄上执行的具体操作。libuv 中有多种请求类型，每种都继承自基础结构 uv_req_t。这些请求负责封装异步操作的上下文和数据，便于在操作完成时通过回调函数通知用户。常见的请求类型包括：
- uv_write_t：表示写入操作，关联着 uv_stream_t 类型的句柄（例如 uv_tcp_t 或 uv_pipe_t），用于异步发送数据。
- uv_connect_t：用于发起连接的请求，例如在 TCP 客户端中使用。
- uv_fs_t：文件系统请求，用于异步执行文件 I/O 操作，如读写文件或目录操作。
请求的特性和操作
- 与句柄的关系：请求与句柄是分离的，这使得一个句柄可以同时进行多个请求。例如，一个 TCP 连接句柄可以同时执行读和写请求。
- 请求队列和并发性：libuv 将请求加入事件循环的队列中，确保它们按顺序处理，使用回调通知用户操作的结果。这种设计允许并发处理多个异步任务，提高程序的响应性和效率。
- 生命周期管理：请求的生命周期通常比单个 I/O 操作短。一旦请求完成并调用了回调，libuv 会将请求从事件循环中移除并释放其相关资源。
回调机制与异步处理
libuv 的异步编程模型依赖于事件驱动和回调函数：
- 非阻塞 I/O：libuv 提供了一种非阻塞的 I/O 操作方式。操作发起时立即返回，通过请求和句柄的组合完成异步处理。
- 事件循环集成：每个事件循环实例管理着一组句柄和请求。当请求完成时，事件循环会调度相关回调，执行用户定义的任务。
代码示例
以下是一个使用 uv_tcp_t 句柄和 uv_connect_t 请求来进行异步 TCP 连接的示例：
#include
void on_connect(uv_connect_t* req, int status) {
if (status < 0) {
fprintf(stderr, "Connection error %s\n", uv_strerror(status));
return;
}
printf("Connected successfully!\n");
// 继续执行数据传输或其他操作
}
int main() {
uv_loop_t* loop = uv_default_loop();
uv_tcp_t client;
uv_connect_t connect_req;
struct sockaddr_in dest;
uv_tcp_init(loop, &client);
uv_ip4_addr("", , &dest);
uv_tcp_connect(&connect_req, &client, (const struct sockaddr*)&dest, on_connect);
uv_run(loop, UV_RUN_DEFAULT);
uv_loop_close(loop);
return 0;
} 在此示例中：
- uv_tcp_t client 是 TCP 连接句柄，管理连接的状态。
- uv_connect_t connect_req 是连接请求，封装连接信息。
- 当连接完成时，on_connect() 回调被调用来处理连接结果。
这种基于句柄和请求的设计使 libuv 能够有效地抽象底层平台的 I/O 操作，支持多种异步操作并实现跨平台兼容性。
异步 I/O 和回调机制
异步 I/O 是 libuv 的核心特性，它通过避免阻塞式 I/O 操作带来的性能瓶颈，为开发非阻塞、高并发应用提供了灵活解决方案。libuv 的异步处理是基于 事件循环 和 回调机制 实现的。
工作流程
- 调用异步 API 程序发起异步操作时调用 libuv 的异步 API，例如文件读取、网络请求等。开发者需要提供一个 回调函数，作为操作完成后的响应逻辑。
- 请求入队 libuv 将请求记录到事件循环的任务队列中，同时立即返回给调用者。此时，调用者可以继续执行其他操作，而无需等待异步操作完成。
- 事件循环处理请求 libuv 的事件循环持续监听所有异步操作的状态。一旦某个操作完成（例如数据准备就绪，或网络连接建立成功），事件循环会调度与该操作关联的回调函数。
- 执行回调函数 回调函数在事件循环中被执行，并根据传递的结果数据执行用户逻辑。
特性与优点
- 非阻塞式 I/O：libuv 的所有 I/O 操作均为非阻塞，极大提升了并发处理能力。
- 高效事件分发：通过事件循环统一调度所有异步任务，避免线程上下文切换的开销。
- 灵活的回调机制：开发者可灵活定义回调函数处理复杂逻辑。
示例代码
以下是 libuv 异步文件读取的示例，展示了异步 API 的调用及回调机制的使用：
#include
#include
#include
void on_read(uv_fs_t* req) {
if (req->result < 0) {
fprintf(stderr, "Read error: %s\n", uv_strerror(req->result));
} else if (req->result == 0) {
// End of file
uv_fs_req_cleanup(req);
free(req->data); // Free buffer
} else {
printf("Read: %s\n", (char*)req->data);
}
uv_fs_req_cleanup(req); // Clean up request resources
}
void on_open(uv_fs_t* req) {
if (req->result < 0) {
fprintf(stderr, "Open error: %s\n", uv_strerror(req->result));
} else {
uv_fs_t* read_req = malloc(sizeof(uv_fs_t));
char* buffer = malloc);
uv_buf_t iov = uv_buf_init(buffer, );
read_req->data = buffer; // Store buffer for later cleanup
uv_fs_read(uv_default_loop(), read_req, req->result, &iov, 1, -1, on_read);
}
uv_fs_req_cleanup(req); // Clean up open request
}
int main() {
uv_loop_t* loop = uv_default_loop();
uv_fs_t open_req;
uv_fs_open(loop, &open_req, "test.txt", O_RDONLY, 0, on_open);
uv_run(loop, UV_RUN_DEFAULT);
uv_loop_close(loop);
return 0;
} 代码解析
- 调用 uv_fs_open 异步打开文件，指定 on_open 为回调。
- 在 on_open 中，调用 uv_fs_read 异步读取文件内容，指定 on_read 为回调。
- 文件读取完成后，on_read 被触发，处理读取结果。
回调机制的挑战与解决方案
- 回调地狱（Callback Hell） 多层嵌套回调会导致代码难以维护和阅读。可以通过 函数分拆 或使用 C++ 包装库（如 libuvpp、uvw）简化代码结构。
- 错误处理 异步操作的错误需要在每个回调中明确处理，例如检查 req->result 是否小于零。
通过异步 I/O 和回调机制，libuv 在性能和灵活性上提供了强有力的支持，非常适合需要高并发和低延迟的应用场景。
非阻塞 I/O 的工作原理
非阻塞 I/O 是 libuv 的核心设计理念之一，通过避免传统阻塞式 I/O 的等待时间，实现了高效的并发处理。libuv 依赖操作系统提供的 I/O 多路复用机制 来监听资源的状态变化，从而在单线程环境下管理多个 I/O 操作。
工作机制
- 注册资源监控 当程序发起 I/O 操作（如文件读写、网络请求）时，libuv 不会立即阻塞线程等待结果，而是将相关 I/O 操作注册到操作系统提供的多路复用接口，例如：
- epoll（Linux）
- kqueue（macOS、FreeBSD）
- IOCP（Windows）
- select/poll（部分系统的回退方案）
- 这些接口允许程序同时监控多个文件描述符，侦测其状态变化（如是否可读、可写）。
- 事件循环监听 libuv 的事件循环调用操作系统的多路复用接口，进入监听状态。在此阶段，线程不会阻塞于某个具体的 I/O 操作，而是处于“挂起等待通知”的状态。
- 响应状态变化 当操作系统检测到某个资源的状态发生变化（例如数据已到达、套接字可写），会通知 libuv 的事件循环。事件循环处理该事件，并调用用户注册的回调函数执行相应操作。
- 回调处理结果 用户的回调函数在事件循环中被触发，处理 I/O 操作的具体逻辑，例如读取数据、发送响应等。
示例代码
以下代码演示了如何在 libuv 中进行非阻塞网络通信：
#include
#include
#include
void on_write(uv_write_t* req, int status) {
if (status < 0) {
fprintf(stderr, "Write error: %s\n", uv_strerror(status));
} else {
printf("Write completed.\n");
}
free(req);
}
void on_connection(uv_stream_t* server, int status) {
if (status < 0) {
fprintf(stderr, "Connection error: %s\n", uv_strerror(status));
return;
}
uv_tcp_t* client = malloc(sizeof(uv_tcp_t));
uv_tcp_init(uv_default_loop(), client);
if (uv_accept(server, (uv_stream_t*)client) == 0) {
uv_write_t* write_req = malloc(sizeof(uv_write_t));
uv_buf_t response = uv_buf_init("Hello, world!", );
uv_write(write_req, (uv_stream_t*)client, &response, 1, on_write);
} else {
uv_close((uv_handle_t*)client, NULL);
}
}
int main() {
uv_loop_t* loop = uv_default_loop();
uv_tcp_t server;
uv_tcp_init(loop, &server);
struct sockaddr_in addr;
uv_ip4_addr("", , &addr);
uv_tcp_bind(&server, (const struct sockaddr*)&addr, 0);
uv_listen((uv_stream_t*)&server, , on_connection);
printf("Listening on port ...\n");
uv_run(loop, UV_RUN_DEFAULT);
uv_loop_close(loop);
return 0;
} 示例解析
- 程序通过 uv_tcp_bind 和 uv_listen 注册了一个非阻塞 TCP 服务。
- 当有新连接到来时，事件循环通过 on_connection 回调处理。
- 客户端连接后，uv_write 异步发送数据，操作完成后调用 on_write 进行确认。
优势
- 高效资源利用：线程不会因 I/O 操作阻塞，可同时处理多个请求。
- 低开销并发：避免线程切换的开销，单线程即可实现高并发。
- 灵活可扩展：通过事件循环统一调度，使得 I/O 操作与业务逻辑分离。
通过非阻塞 I/O 和事件驱动机制，libuv 在高并发环境下展现了卓越的性能表现，是构建网络服务、文件操作等应用的核心基础。
libuv中的数据结构及关系
libuv 的核心功能通过一系列数据结构实现，这些结构主要围绕 事件循环 和 资源管理，实现了异步 I/O 的抽象和管理。以下是 libuv 中重要的数据结构及其关系解析：
- 核心数据结构
(1) uv_loop_t
事件循环的核心结构，负责管理所有异步操作的状态和调度。
- 作用：
- 维护 I/O 多路复用接口（如 epoll 或 kqueue）的文件描述符。
- 调度回调函数和处理异步操作队列。
- 主要字段：
- backend_fd：指向底层多路复用接口（如 epoll 文件描述符）。
- watcher_queue：存储需要监听的 I/O 句柄队列。
- timer_heap：定时器堆，用于管理定时操作。
- pending_reqs_tail：挂起的异步请求队列。
(2) uv_handle_t
句柄是 libuv 的核心抽象，用于表示可操作的资源（如网络连接、文件、定时器等）。所有具体句柄类型都继承自 uv_handle_t。
- 作用：
- 描述资源的通用属性和操作状态。
- 提供对句柄生命周期的统一管理（如引用计数和关闭处理）。
- 主要字段：
- flags：标识句柄状态（如是否正在关闭）。
- loop：关联的事件循环。
- close_cb：句柄关闭后的回调函数。
- 继承结构：
- uv_tcp_t、uv_udp_t、uv_timer_t 等均为 uv_handle_t 的子类型。
(3) uv_req_t
请求表示对句柄资源的具体操作（如写请求、读取请求）。请求与句柄分离，使 libuv 可以同时处理多个异步任务。
- 作用：
- 封装具体操作的参数和回调函数。
- 管理请求的状态和结果。
- 主要字段：
- type：请求类型（如写请求 UV_WRITE）。
- cb：请求完成后的回调函数。
- data：用户数据。
- 继承结构：
- uv_write_t（写请求）、uv_connect_t（连接请求）等。
- 数据结构的关系
libuv 中的数据结构通过继承和组合实现了高度模块化的设计：
关键点总结
- 事件循环 (uv_loop_t) 是调度中心，管理所有异步操作的生命周期。
- 句柄 (uv_handle_t) 表示具体的资源，每种资源有特定的子类（如 TCP、UDP）。
- 请求 (uv_req_t) 代表对资源的具体操作，解耦了操作和资源。
这种设计使 libuv 既能支持多种异步操作，又能保持代码简洁、灵活，适用于构建高并发网络服务器等应用场景。