GRPC Async_Client中的内存泄漏

我使用gRPCasync client的方式与使用example类似。

在这个例子中(发布在gRPC官方github中)，客户端为要发送的消息分配内存，使用tag的地址作为completion queue的地址，当消息在监听器线程中被应答时，内存(称为tag-地址)是空闲的。

我担心服务器没有响应消息并且内存永远不会空闲的情况。

• gRPC是否可以保护我免受这种情况的影响？
• 我应该以不同的方式实现它吗？(使用智能指针/将指针保存在数据结构中/等...)

异步客户端发送功能

void SayHello(const std::string& user) {
    // Data we are sending to the server.
    HelloRequest request;
    request.set_name(user);

    // Call object to store rpc data
    AsyncClientCall* call = new AsyncClientCall;

    // Because we are using the asynchronous API, we need to hold on to
    // the "call" instance in order to get updates on the ongoing RPC.
    call->response_reader =
        stub_->PrepareAsyncSayHello(&call->context, request, &cq_);

    // StartCall initiates the RPC call
    call->response_reader->StartCall();

    call->response_reader->Finish(&call->reply, &call->status, (void*)call);

}

异步客户端线程接收函数

void AsyncCompleteRpc() {
    void* got_tag;
    bool ok = false;

    // Block until the next result is available in the completion queue "cq".
    while (cq_.Next(&got_tag, &ok)) {
        // The tag in this example is the memory location of the call object
        AsyncClientCall* call = static_cast<AsyncClientCall*>(got_tag);

        // Verify that the request was completed successfully. Note that "ok"
        // corresponds solely to the request for updates introduced by Finish().
        GPR_ASSERT(ok);

        if (call->status.ok())
            std::cout << "Greeter received: " << call->reply.message() << std::endl;
        else
            std::cout << "RPC failed" << std::endl;

        // Once we're complete, deallocate the call object.
        delete call;
    }
}

Main

int main(int argc, char** argv) {


    GreeterClient greeter(grpc::CreateChannel(
            "localhost:50051", grpc::InsecureChannelCredentials()));

    // Spawn reader thread that loops indefinitely
    std::thread thread_ = std::thread(&GreeterClient::AsyncCompleteRpc, &greeter);

    for (int i = 0; i < 100; i++) {
        std::string user("world " + std::to_string(i));
        greeter.SayHello(user);  // The actual RPC call!
    }

    std::cout << "Press control-c to quit" << std::endl << std::endl;
    thread_.join();  //blocks forever

    return 0;
}

---

解决方案

GRPC是否会保护我免受这种情况的影响？

金达。GRPC保证所有排队的操作迟早都会在匹配的完成队列中结束。因此，只要：

，您的代码就可以了

• 在不合适的时间不引发任何异常。
• 不更改创建不包括将操作排队或删除调用的代码路径的代码。

换句话说：还可以，但很脆弱。

选项A：

如果您想要真正健壮，方法是std::shared_ptr<>。然而，它们可能会以意想不到的方式扰乱多线程性能。因此，它是否值得取决于你的应用程序在性能和健壮性方面的表现。

这样的重构将如下所示：

1. 从std::enable_shared_from_this继承AsyncClientCall
2. 将call的结构改为std::make_shared<AsyncClientCall>()
3. 在完成队列处理程序中，增加引用计数：

while (cq_.Next(&got_tag, &ok)) {
    auto call = static_cast<AsyncClientCall*>(got_tag)->shared_from_this();

，并明显地去掉delete。

选项B：

您还可以使用unique_ptr<>：

获得一个像样的中值

    auto call = std::make_unique<AsyncClientCall>();
    ...
    call->response_reader->Finish(&call->reply, &call->status, (void*)call.release());

和

    std::unique_ptr<AsyncClientCall> call{static_cast<AsyncClientCall*>(got_tag)};

这可以防止重构和异常，同时维护其他所有内容。但是，这仅适用于生成单个完成事件的一元RPC。流RPC或交换元数据的RPC需要完全不同的处理。