悬挂指针指指向已释放内存的指针，产生于内存释放后未置空、返回局部变量地址等场景，导致未定义行为、内存损坏、程序崩溃及安全漏洞；解决方法包括释放后置空、使用智能指针、避免返回局部变量地址、采用容器和RAII原则，并借助静态分析与代码审查预防。
C++中的悬挂指针（Dangling Pointer）指的是一个指针，它指向的内存区域已经被释放（deallocated）或不再有效。简单来说，就是你拿着一个地址，但这个地址所代表的房子已经被拆掉了。当你试图通过这个指针访问或修改那块“不存在”的内存时，就会导致程序出现未定义行为。
解决方案
悬挂指针的出现，通常是由于内存管理不当造成的。在C++中，当我们手动使用
new
和
delete
来管理内存时，就为悬挂指针的产生埋下了隐患。一旦一块内存被
delete
释放，操作系统就会认为这块内存可以被重新分配给其他程序或同一程序的其他部分使用。然而，如果此时我们之前指向这块内存的指针没有被及时置空（
nullptr
），它就成了一个悬挂指针。
举个例子：
int* p = new int; // 分配一块内存，p指向它*p = 10;// ... 使用p指向的内存 ...delete p; // 释放p指向的内存// 此时，p仍然指向那块已经被释放的内存，它现在是一个悬挂指针！// 如果我们不小心再次使用p：// *p = 20; // 访问已释放内存，未定义行为！可能导致崩溃或数据损坏// int x = *p; // 读取已释放内存，未定义行为！可能读到垃圾数据
这种情况下，程序可能不会立即崩溃，但其行为变得不可预测。它可能会在运行时表现出奇怪的错误、数据损坏，甚至在不同的运行环境或编译器下产生不同的结果，这无疑是调试的噩梦。
立即学习“C++免费学习笔记（深入）”；
悬挂指针是如何产生的？
在我看来，悬挂指针的产生主要有几个常见场景，它们都是对内存生命周期管理不当的体现：
内存被
delete
后未置空：这是最经典也最常见的情况。如上例所示，当我们手动
delete
一块内存后，如果忘记将对应的指针设置为
nullptr
，那么这个指针就“悬空”了。它还“记得”那个地址，但那块地址已经不再属于我们了。
局部变量的地址被返回：函数内部的局部变量（非静态）存储在栈上，当函数执行完毕，栈帧被销毁，这些局部变量也就不复存在了。如果一个函数返回了某个局部变量的地址，那么在函数外部接收这个地址的指针，就成了悬挂指针。
int* createDanglingPointer() { int local_var = 100; return &local_var; // local_var在函数返回后被销毁}// 在main函数中：// int* dp = createDanglingPointer();// std::cout << *dp; // 未定义行为，dp是一个悬挂指针
作用域结束导致对象销毁：当一个指针指向的对象在某个作用域内被创建，而该作用域结束后对象被销毁，但指针本身仍然存在于更大的作用域中时，也会产生悬挂指针。这在处理C风格字符串或数组时尤其容易发生。
char* p;{ char buffer[20]; // 栈上数组 // ... 填充buffer ... p = buffer; // p指向buffer的起始地址} // buffer在此处被销毁// 此时，p是一个悬挂指针，指向已销毁的栈内存// std::cout << p; // 未定义行为
双重释放（Double Free）：如果同一块内存被
delete
了两次，第一次
delete
后，指针就成了悬挂指针。第二次
delete
会尝试释放一块已经释放的内存，这通常会导致堆损坏，引发更严重的程序崩溃。
int* p = new int;// ...delete p;// p = nullptr; // 如果忘记这一步// ... 稍后不小心再次delete p ...delete p; // 双重释放，严重错误！
悬挂指针的危害有哪些？
在我多年的编程经验里，悬挂指针绝对是C++中最令人头疼的Bug之一，它的危害是多方面且深远的：
未定义行为（Undefined Behavior, UB）：这是悬挂指针最核心的危害。一旦触发UB，程序可能做任何事情：崩溃、静默地产生错误结果、被恶意利用（安全漏洞）、或者在不同环境下表现出完全不同的行为。这意味着你的程序不再可控，无法预测其行为。
内存损坏（Memory Corruption）：当你通过一个悬挂指针写入数据时，你实际上是在写入一块你不再拥有的内存。这块内存可能已经被操作系统重新分配给了程序的其他部分，或者其他正在运行的进程。你的写入操作可能会无意中覆盖掉其他重要的数据结构、变量，甚至系统内部的数据，导致程序逻辑混乱，最终崩溃。
程序崩溃（Segmentation Fault/Access Violation）：访问已释放的内存常常会触发操作系统的内存保护机制。操作系统会检测到你试图访问一块不属于你的内存区域，从而终止你的程序，通常表现为“段错误”（Segmentation Fault）或“访问冲突”（Access Violation）。虽然这看起来是直接的错误，但它通常发生在悬挂指针被“激活”的那一刻，而不是它被创建的那一刻，这让追溯问题变得困难。
安全漏洞：在某些情况下，特别是服务器或长期运行的应用程序中，悬挂指针可能被恶意利用。攻击者可以通过精心构造的输入，诱导程序触发悬挂指针，然后利用其对内存的非预期访问来执行任意代码，或者泄露敏感信息，从而导致严重的安全漏洞。
难以调试：悬挂指针的Bug往往是间歇性的，难以复现。程序可能在数千次运行中都正常，然后突然崩溃。崩溃点往往与悬挂指针的创建点相距甚远，导致调试器指向的错误位置并不是问题的根源。这就像在茫茫大海中寻找一根针，非常耗时耗力。
数据泄露：虽然不常见，但在某些场景下，如果被释放的内存没有被立即覆盖，悬挂指针可能会让你读取到之前存储在那里的敏感数据。如果这块内存随后被重新分配给不应该访问这些数据的部分，就可能导致信息泄露。
如何有效避免C++中的悬挂指针？
避免悬挂指针，在我看来，是编写健壮、安全C++代码的关键一步。以下是一些行之有效的方法：
释放内存后立即将指针置空：这是最直接、最基础的防御措施。每次调用
delete
后，都应该紧接着将对应的指针设置为
nullptr
。这样，即使后续代码不小心再次使用这个指针，它也会尝试解引用
nullptr
，这通常会立即导致程序崩溃（在大多数操作系统上），而不是悄无声息地破坏内存，这反而更容易被调试器捕获。
int* p = new int;// ...delete p;p = nullptr; // 关键一步！// 再次使用p时，if (p != nullptr) 可以安全检查
拥抱智能指针（Smart Pointers）：这是现代C++避免悬挂指针和内存泄漏的“银弹”。智能指针通过RAII（Resource Acquisition Is Initialization）原则，将内存管理与对象的生命周期绑定。当智能指针超出作用域时，它会自动释放所管理的内存。
std::unique_ptr
：实现独占所有权。一个
unique_ptr
只能指向一块内存，不能被复制，只能被移动。当
unique_ptr
被销毁时，它所指向的内存也会被自动释放。这是默认推荐的智能指针，除非你需要共享所有权。
std::shared_ptr
：实现共享所有权。多个
shared_ptr
可以指向同一块内存，内部通过引用计数来管理内存。只有当最后一个
shared_ptr
被销毁时，内存才会被释放。
std::weak_ptr
：配合
shared_ptr
使用，用于打破循环引用。
weak_ptr
不增加引用计数，因此不会阻止
shared_ptr
指向的内存被释放。它提供了一种非拥有性的引用方式，可以用来安全地检查资源是否仍然存在。
使用智能指针，你几乎不需要手动调用
delete
，大大降低了悬挂指针的风险。
避免返回局部变量的地址：这是C++初学者常犯的错误。局部变量在函数栈帧上，函数返回时会被销毁。如果确实需要返回数据，应该返回数据本身（如果数据量小），或者返回动态分配的内存（并用智能指针管理），或者通过引用/指针参数将结果写入调用者提供的内存。
使用容器而非裸数组：对于动态大小的数组，
std::vector
是比裸指针和
new[]
/
delete[]
更安全、更方便的选择。
std::vector
会自动管理其内部存储，当
vector
超出作用域时，其内存会被正确释放，避免了悬挂指针和内存泄漏的风险。
遵循RAII原则：RAII（Resource Acquisition Is Initialization）是C++中管理资源的核心思想。它意味着资源（如内存、文件句柄、锁等）在对象构造时获取，在对象析构时释放。智能指针就是RAII的典型应用。将资源管理封装在类中，让析构函数负责清理工作，可以确保资源在任何情况下都能被正确释放。
静态代码分析工具：利用现代IDE或专门的静态代码分析工具（如Clang-Tidy, PVS-Studio, SonarQube等），它们可以在编译前扫描代码，识别潜在的内存管理问题，包括一些悬挂指针的场景。
代码审查：人类的眼睛和思维仍然是发现Bug的强大工具。定期的代码审查，尤其是关注内存管理和指针使用的部分，可以帮助团队成员之间互相发现和修正潜在的悬挂指针问题。
总而言之，理解内存生命周期、合理使用智能指针、并遵循良好的编程实践，是告别悬挂指针噩梦的关键。
以上就是C++中什么是悬挂指针（Dangling Pointer）以及它的危害的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1473891.html
微信扫一扫 
支付宝扫一扫 
