在类析构函数中用线程销毁shared_ptr成员变量是否合规？

Let's tackle your two questions one by one, and unpack the underlying issues with your approach to make things clearer.

1. Is resetting a smart pointer this way wrong? #

Yes, this pattern is problematic and almost certainly the cause of your heap corruption concerns. Here's the breakdown:

When your Bar class's destructor runs, the object is already in the process of being destroyed. Object destruction follows this sequence:

1. Execute the code inside the destructor body
2. Destroy all member variables in reverse order of their declaration

If you launch a thread inside the destructor to reset the shared_ptr member:

• With std::join(), the destructor blocks until the thread finishes. Since we haven’t reached step 2 yet, the shared_ptr member still exists, so the reset operation is technically safe here. But this is still a bad practice—destructors should be simple, synchronous cleanup routines. Introducing threads complicates the object’s lifecycle and creates fragile code that can break if you make even small changes later.
• With std::detach(), the thread runs independently of the destructor. The destructor will finish executing, and then the shared_ptr member will be destroyed. If the detached thread tries to reset the shared_ptr after it’s already been destroyed, you’re accessing a destroyed object—this is undefined behavior, which can manifest as heap corruption, crashes, or unpredictable program behavior.

Even with join(), relying on this pattern is risky. A destructor’s core job is to clean up the object’s own resources synchronously, not offload work to a separate thread.

2. Why isn't the destructor called when using std::detach()? #

This is likely a misunderstanding or a side effect of how detached threads interact with process lifecycle. Let’s look at the most common scenarios:

• The process exits before the destructor completes: If your Bar object is a local variable in main() (or another function that exits quickly), using detach() means the destructor doesn’t wait for the thread to finish. The main thread continues, exits the function, and the process terminates. When a process ends, the OS reclaims all its resources immediately—remaining threads are killed, and pending destructor calls (like for global objects) might not execute fully. This can make it seem like the destructor wasn’t called, when in reality it might have started but didn’t finish, or its output was lost because the process exited too quickly.
• Undefined behavior crashes the program: If the detached thread tries to access the shared_ptr member after the Bar object has been destroyed, this triggers undefined behavior. The program might crash right after the destructor launches the thread, before the destructor can finish executing. This makes it look like the destructor never ran, when it actually crashed mid-execution.

To test this, add std::cout statements at the start and end of the Bar destructor. With detach(), you might see the start message but not the end (if the process exits or crashes), whereas with join() you’ll see both.

A Better Approach #

Instead of mixing destructors and threads for this cleanup, consider:

• Resetting the shared_ptr directly in the destructor body (no threads needed—this is the simplest, safest approach).
• If you truly need asynchronous cleanup, add a separate shutdown() method that launches the cleanup thread and uses join() to wait for it to finish before allowing the object to be destroyed. This gives you explicit control over the lifecycle and avoids the risks of threading in destructors.

内容的提问来源于stack exchange，提问作者ark1974