答案：C++中new和delete用于动态内存分配，解决运行时未知大小、对象生命周期延长及大内存需求等问题，但易引发内存泄漏、悬空指针等风险；现代C++推荐使用智能指针如std::unique_ptr和std::shared_ptr实现RAII，自动管理资源，提升安全性与代码简洁性。
C++进行动态内存分配的核心在于
new
和
delete
这两个操作符。它们允许程序在运行时，根据需要从堆（heap）上申请内存，并在不再需要时将其归还，这与在栈（stack）上自动管理内存的方式形成了互补。
解决方案
在C++中，当你需要一个对象的生命周期不局限于其所在的代码块，或者其大小在编译时无法确定时，动态内存分配就显得尤为重要。
new
操作符负责在堆上分配指定大小的内存，并为对象调用构造函数（如果它是类类型），然后返回一个指向这块内存起始地址的指针。
例如，分配一个整型变量：
int* p_int = new int;
或者分配一个包含10个整型元素的数组：
int* p_array = new int[10];
使用
new
时，如果内存分配失败，它默认会抛出
std::bad_alloc
异常。如果你不希望抛出异常，而是想检查返回的指针是否为空，可以使用
std::nothrow
版本：
int* p_int_safe = new (std::nothrow) int;
此时，如果分配失败，
p_int_safe
将为
nullptr
。
当动态分配的内存不再需要时，必须使用
delete
操作符将其释放。
delete
会为对象调用析构函数（如果它是类类型），然后将内存归还给系统。
释放单个对象：
delete p_int;
释放数组：
delete[] p_array;
划重点：
new
必须与
delete
配对使用，
new[]
必须与
delete[]
配对使用。这种匹配是强制性的，否则会导致未定义行为，轻则内存泄漏，重则程序崩溃。释放内存后，一个好的习惯是立即将指针置为
nullptr
，以避免悬空指针（dangling pointer）问题。
立即学习“C++免费学习笔记（深入）”；
为什么我们需要动态内存分配？它解决了哪些编程难题？
我个人觉得，动态内存分配是C++赋予程序员强大能力的一个体现，它主要解决了几个核心的编程难题，这些难题在静态或栈内存分配模型下是无解的：
一个很明显的场景是数据结构的弹性大小。设想你需要读取一个文件，但文件中有多少行、每行多长，你事先根本不知道。如果用静态数组，你得预设一个最大值，这通常意味着内存浪费或者容量不足。而动态内存分配允许你在运行时根据实际需求来申请内存，比如读到文件末尾才知道需要一个多大的数组来存储所有数据。
再者，是对象生命周期的管理。栈上的对象，一旦其所在函数返回，就会被自动销毁。但很多时候，我们希望一个对象在创建它的函数结束后仍然存在，例如，一个全局配置对象、一个需要跨多个函数甚至模块传递的数据结构。通过
new
创建的对象，它的生命周期可以由程序员精确控制，直到
delete
被调用。这对于实现复杂的数据结构，比如链表、树、图等，是不可或缺的。因为这些结构的节点往往需要独立于创建它们的函数而存在。
还有就是应对大内存需求。栈内存的大小是有限的，通常只有几MB。如果你的程序需要处理一个非常大的数组或者一个复杂的对象图，比如一个高分辨率的图像缓冲区，栈内存可能根本不够用。堆内存则通常大得多，可以满足这些需求。虽然这听起来有点像在说废话，但实际开发中，因为栈溢出导致程序崩溃的情况并不少见。
new
new
和
delete
使用中常见的陷阱与最佳实践是什么？
在使用
new
和
delete
时，就像走钢丝，一步不慎就可能掉入深渊。最常见的陷阱，也是我见过同事们（包括我自己）犯过最多的错误，就是内存泄漏（Memory Leak）。简单来说，就是你
new
了一块内存，但忘记
delete
它了。这块内存就一直被你的程序占用着，但又无法访问，直到程序结束才被操作系统回收。长期运行的程序如果出现内存泄漏，最终会导致系统资源耗尽，拖垮整个系统。一个常见的场景是，在循环中
new
对象，但没有对应的
delete
，或者在函数中
new
了一个对象，但在函数返回前没有
delete
，如果函数提前通过异常退出，也可能导致泄漏。
另一个让人头疼的问题是悬空指针（Dangling Pointer）和重复释放（Double Free）。当你
delete
了一块内存后，如果对应的指针没有被置为
nullptr
，它仍然指向那块现在已经无效的内存区域。这个指针就成了悬空指针。之后如果程序通过这个悬空指针去访问内存，就可能读到垃圾数据，甚至写入到已经被释放或被其他数据占用的区域，造成难以调试的崩溃。更糟的是，如果你再次
delete
这个悬空指针，那就是重复释放同一块内存，这几乎必然导致程序崩溃或更隐蔽的内存损坏。
最佳实践在我看来，围绕的核心思想就是资源管理。
配对使用，及时释放： 任何
new
操作都应该有对应的
delete
。如果是在函数内部分配的，确保在所有可能的退出路径（包括正常返回和异常抛出）上都能被释放。释放后置空： 这是一个小习惯，但能有效避免悬空指针和重复释放。
delete ptr; ptr = nullptr;
RAII原则： 这是C++中管理资源的核心思想——资源获取即初始化（Resource Acquisition Is Initialization）。这意味着将资源的生命周期绑定到一个对象的生命周期上。当对象创建时获取资源，当对象销毁时（通过析构函数）释放资源。这正是智能指针的底层原理。异常安全： 考虑当代码在
new
和
delete
之间抛出异常时，内存是否能被正确释放。手动管理内存很难做到这一点，这也是为什么现代C++极力推荐使用智能指针的原因。避免原始指针的”所有权”： 尽量避免让原始指针拥有它指向的内存。如果一个函数返回一个
new
出来的指针，那么谁来
delete
它？这会造成所有权模糊，导致管理混乱。
现代C++中，我们是否还应该直接使用
new
new
和
delete
？智能指针的角色是什么？
在我看来，在现代C++编程中，直接使用
new
和
delete
的场景已经越来越少，甚至可以说，在大多数情况下应该避免。 并不是说它们不好，而是它们太容易出错，而且现代C++提供了更安全、更高效的替代方案：智能指针。
智能指针是遵循RAII原则的类模板，它们包装了原始指针，并在自身生命周期结束时自动调用
delete
或
delete[]
来释放内存。这极大地简化了内存管理，并有效避免了内存泄漏、悬空指针和重复释放等常见问题。
std::unique_ptr
： 顾名思义，它表示独占所有权。一个
unique_ptr
只能指向一块内存，并且不能被复制，但可以被移动。这意味着内存资源的所有权可以从一个
unique_ptr
转移到另一个，但始终只有一个
unique_ptr
拥有它。当
unique_ptr
超出作用域时，它会自动释放所管理的内存。这非常适合那些只有单一所有者、且生命周期明确的动态分配对象。例如：
std::unique_ptr obj = std::make_unique();
std::shared_ptr
： 这种智能指针允许多个
shared_ptr
实例共同拥有同一块内存。它通过引用计数（reference count）来跟踪有多少个
shared_ptr
指向这块内存。当最后一个
shared_ptr
被销毁时，它所管理的内存才会被释放。这对于实现共享资源非常有用，比如一个配置对象或一个大型数据结构，多个模块都需要访问它，但又不知道谁会是最后一个使用者。例如：
std::shared_ptr data = std::make_shared();
std::weak_ptr
： 它是一种非拥有型智能指针，通常与
std::shared_ptr
配合使用。
weak_ptr
可以观察
shared_ptr
所管理的资源，但不会增加引用计数。它的主要作用是解决
shared_ptr
可能导致的循环引用问题，避免内存泄漏。
那么，什么时候我们还会直接使用
new
和
delete
呢？
老实说，在我的日常工作中，直接使用它们的频率已经非常低了。可能有一些非常特殊的场景：
自定义内存分配器： 如果你需要实现自己的内存池或者特殊的内存管理策略，那么你可能需要直接操作
new
和
delete
。与C语言API交互： 有些C语言库的API可能要求你传入一个原始指针，并且它内部会负责释放，或者要求你使用特定的C函数来分配和释放内存。实现自己的智能指针或容器： 如果你在学习或开发底层库，可能会需要自己实现类似的内存管理机制。性能敏感的场景（极少）： 在某些对性能有极致要求的场景下，如果智能指针的少量额外开销都无法接受，可能会考虑直接使用
new
/
delete
。但这通常需要非常严谨的设计和测试。
总而言之，现代C++的最佳实践是优先使用智能指针，尤其是
std::make_unique
和
std::make_shared
来创建动态对象，让编译器和库来帮你处理内存管理。只有在确实有充分理由，并且清楚了解其风险和后果的情况下，才考虑直接使用
new
和
delete
。这不仅能提高代码的健壮性，也能让你的精力更多地放在业务逻辑上，而不是繁琐且易错的内存管理细节上。
以上就是c++++如何进行动态内存分配_c++ new与delete内存管理技巧的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1476264.html
微信扫一扫 
支付宝扫一扫 
