libuv使用的若干个坑

最开始考虑使用muduo，但是仔细看了一下，觉得很多地方其实没有书里写的那么好，网上讨论见到有一个国人做了uvcpp，号称在游戏服务器上运行稳定，我看一下代码还有很多值得借鉴的地方，但是还是有很多不是我喜欢的实现方式，于是自己重新封装了一遍，过程比较艰辛，因为网上资料并不太多，里面很多坑……

我封装的uv-rpc单次往返时延在0.2ms左右，单链接每秒可以调用256字节的命令2万多次。

https://github.com/robinfoxnan/uv-rpc

分享一下封装过程中遇到的问题和一些心得，取之于网，还之于网，希望对大家有用。

1）线程安全与调用方式

        不正确的使用可能造成程序崩溃，或者函数不起作用！！！我在github官方询问，人家根本没有搭理我，老外直接关闭了issue，shit!

        遇到这样的问题是因为： 除了uv_async_send和uv_queue_work是客户代码可以安全调用的，其他的函数应该在loop回调中调用；loop中几乎几处使用锁，所以并非线程安全的，可以认为不同的线程间无法直接调用对方管理的资源。

        官方示例代码都是先调用函数，比如connect ，再启动loop循环，这样是没有问题的；最后执行uv_run()

int main() {
    loop = uv_default_loop();

    uv_tcp_t server;
    uv_tcp_init(loop, &server);

    uv_ip4_addr("0.0.0.0", DEFAULT_PORT, &addr);

    uv_tcp_bind(&server, (const struct sockaddr*)&addr, 0);
    int r = uv_listen((uv_stream_t*) &server, DEFAULT_BACKLOG, on_new_connection);
    if (r) {
        fprintf(stderr, "Listen error %s\n", uv_strerror(r));
        return 1;
    }
    return uv_run(loop, UV_RUN_DEFAULT);
}

        但是当先启动了loop循环，之后在其他线程里发送数据uv_write，或者调用定时器，或者调用close之类的操作就不一定会成功，还可以能会崩溃。这个问题搞的我也很崩溃，后来搜索到了必须要在loop回调中调用非安全的函数。

        解决方法是在uv_async_send中回调函数中执行要需要执行的代码段，具体可以使用lamda表达式。具体封装方式见：https://github.com/robinfoxnan/uv-rpc/blob/main/src/EventLoop.cpp 

        此类操作主要包括：uv_read_start，uv_write，uv_close，等等，比如我们要在某个loop循环中启动一个定时器应该如下使用：

void test()
{
	EventLoop * loop = new EventLoop();
	loop->runInLoopEn([=]()
	{
		UvTimer* uvTimer = new UvTimer(loop, 5, 5, [](UvTimer* t)
		{
			printf("test\n");
			t->stop();
			t->close([](UvTimer* t)
			{
				printf("delete\n");
				delete t;
			});
		});
		uvTimer->start();
	});
	loop->run();
}

而绝对不可以在随便一个线程中就uv_start_timer，可能根本就不会有回调发生！！！！

2）loop线程模型

        默认的libuv提供了一个uv_default_loop()可以返回一个全局的loop结构体，官方很多示例都是使用此类操作；

        启动loop循环时默认的运行方式uv_run(loop, UV_RUN_DEFAULT)会阻塞线程，所以需要在一个线程中使用；loop本身是一个循环，所以异步操作的时间都需要在loop上等待回调，并且在该loop线程中完成回调。如果回调的动作很大，耗时很长，则会阻塞其他的操作；

        所以我的方式是server使用一个loop用来listen，再通过配置变量启动多个IO线程，每个线程上分别执行一个loop循环，新接入的socket分配到不同的线程循环上处理各自的读写事件，这样就可以达到多核并发的效果；否则所有的SOCKET上都在一个线程上，肯定是快不了的。

        即便是这样，我在IO线程中编解码，但是耗时长的CPU密集型操作还是不能在这里做，则需要将数据解析为TASK使用任务线程池处理。见下一节。

        其实还有一个问题，那就是loop循环中，如果没有激活的句柄需要操作，循环就会退出，那么那么怎么保证loop中有句柄可以处理，而不会直接退出呢？其实EventLoop中封装一个默认的异步事件，那么loop就不会退出。EventLoop类做了具体实现。

关于如何启动多个IO线程，具体代码参考：

https://github.com/robinfoxnan/uv-rpc/blob/main/src/ConnectionManager.cpp

启动多个IO线程：

for (int i = 0; i < n; i++)
	{
		EventLoopPtr ptr = std::make_shared<EventLoop>();
		loopVector.push_back(ptr);
		ssize_t index = loopVector.size();
		threadVector.push_back(std::thread([ptr, index]()
		{

			printf("io thread %jd start\n", index);
			ptr->run();
			printf("io thread %jd exit\n", index);
		}));
	}

3）线程池

        在uv中集成了工作线程池模型，直接调用uv_queue_work就可以安排函数执行；uv会检查是否初始化过线程池，如果没有初始化过，会根据参数建立若干个工作线程，（默认是4个），不过可以通过设置环境变量来更改工作线程个数；

需要说的是，我们的函数如果耗时很长，则在工作线程上执行，执行后，会返回调用的loop线程，执行after_work函数，也就是接收到数据的那个loop线程，在这里发送返回的数据相对比较合适。

https://github.com/robinfoxnan/uv-rpc/blob/main/src/WorkerPool.cpp

工作线程的执行流程网上很多分析，此处不再赘述。

4) 内存池

        关于使用智能指针还是内存池，我觉得各有优点，首先我觉得作为网络应用来说，使用的内存块相对比较固定，使用内存池可以避免频繁的分配和释放内存。很多牛逼的C程序都使用了内存池技术。比如glusterFS。

        而且libuv提供了分配内存的回调函数，可以完美的支持自己的内存管理，所以我也做了一个。

        对于读操作，我使用固定大小的内存块，因为在编码时候约定不超过某个值；对于写操作，很多人使用string或者std::vector<char>，我最终没有使用vector来管理，因为测试发现vector还是很慢的，所以我自己做一个CharVector用来序列化json和protobuf数据，

https://blog.csdn.net/robinfoxnan/article/details/118760091?spm=1001.2014.3001.5501

同时，也可以使用libuv的快速队列来管理数据：https://github.com/robinfoxnan/uv-rpc/blob/main/include/BufferQue.h，但是暂时没有使用。

下面是官方的tcp-echo-server文件演示的简单服务器。

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <uv.h>

#define DEFAULT_PORT 7000
#define DEFAULT_BACKLOG 128

uv_loop_t *loop;
struct sockaddr_in addr;

typedef struct {
    uv_write_t req;
    uv_buf_t buf;
} write_req_t;

void free_write_req(uv_write_t *req) {
    write_req_t *wr = (write_req_t*) req;
    free(wr->buf.base);
    free(wr);
}

// 我理解，给这个接口是为了大家使用自己的内存池
void alloc_buffer(uv_handle_t *handle, size_t suggested_size, uv_buf_t *buf) {
    buf->base = (char*) malloc(suggested_size);
    buf->len = suggested_size;
}

void on_close(uv_handle_t* handle) {
    free(handle);
}

void echo_write(uv_write_t *req, int status) {
    if (status) {
        fprintf(stderr, "Write error %s\n", uv_strerror(status));
    }
    free_write_req(req);
}

void echo_read(uv_stream_t *client, ssize_t nread, const uv_buf_t *buf) {
    if (nread > 0) {
        write_req_t *req = (write_req_t*) malloc(sizeof(write_req_t));
        req->buf = uv_buf_init(buf->base, nread);
        uv_write((uv_write_t*) req, client, &req->buf, 1, echo_write);
        return;
    }
    if (nread < 0) {
        if (nread != UV_EOF)
            fprintf(stderr, "Read error %s\n", uv_err_name(nread));
        uv_close((uv_handle_t*) client, on_close);
    }

// 这里有时buf->base是NULL
    free(buf->base);
}

void on_new_connection(uv_stream_t *server, int status) {
    if (status < 0) {
        fprintf(stderr, "New connection error %s\n", uv_strerror(status));
        // error!
        return;
    }

    uv_tcp_t *client = (uv_tcp_t*) malloc(sizeof(uv_tcp_t));
    uv_tcp_init(loop, client);
    if (uv_accept(server, (uv_stream_t*) client) == 0) {
        uv_read_start((uv_stream_t*) client, alloc_buffer, echo_read);
    }
    else {
        uv_close((uv_handle_t*) client, on_close);
    }
}

int main() {
    loop = uv_default_loop();

    uv_tcp_t server;
    uv_tcp_init(loop, &server);

    uv_ip4_addr("0.0.0.0", DEFAULT_PORT, &addr);

    uv_tcp_bind(&server, (const struct sockaddr*)&addr, 0);
    int r = uv_listen((uv_stream_t*) &server, DEFAULT_BACKLOG, on_new_connection);
    if (r) {
        fprintf(stderr, "Listen error %s\n", uv_strerror(r));
        return 1;
    }
    return uv_run(loop, UV_RUN_DEFAULT);
}

这里其实有几个问题：

• 频繁的申请和释放内存，效率低不说，而且会造成内存碎片；
• 注意：当客户端直接关闭退出程序，服务端会收到一个echo_read，这时有可能buf是nullptr，也可能nRead==0； 此时执行free buf其实如果使用内存池，则需要检测是否需要释放到池，否则下次从池里拿到一个空值！（所以glusterfs内存块都加了标记，检测是否是自己的）

5）读写操作

• libuv的行为和socket的常规不太一样，比如read操作读到返回值0应该是对方关闭了；但是libuv其实经常会在回调函数中遇到0字节的读回调，官方示例代码也是不处理此情况；
• 读返回值为负数，则是错误，应该执行close操作；
• 写或者写回调的返回值为负数，则是错误，应该执行close操作；
• close回调结束时，就是安全的释放TcpConnection实例以及涉及的资源了，需要注意要清理相关的lamda表达式回调函数！！！

6) lamda表达式与智能指针

在封装过程中，为了简单，我使用了很多的lamda表达式作为回调函数，但是涉及到shared_ptr需要千万小心！！！

lamda表示使用[=]捕获，或者使用[&]，或者捕获了智能指针shared_ptr，则会在闭包中保存一个引用，也就是增加了智能指针的引用计数，

一不小心，就会造成内存泄露，解决发方法是：

• 将保存lamda表达式发回调函数变量设置为nullptr
• 具体参考
• https://blog.csdn.net/robinfoxnan/article/details/119148102?spm=1001.2014.3001.5501

备注：

vs2017编译libuv

libuv:
mkdir build
cd build
cmake .. -G "Visual Studio 15 2017" -A x64