Python内存安全吗？

Question

由于Deno是Node.js的新竞争对手，许多新闻文章都提到了锈菌的内存安全特性，有一篇文章指出锈蚀和围棋对它们的记忆安全性质有好处，斯威夫特和科特林也是如此，但后两者并没有被广泛用于系统编程。

安全锈蚀是真正的锈蚀编程语言。如果你所做的只是写“安全锈蚀”，你将永远不必担心类型安全或内存安全。你将永远不会忍受一个悬空的指针，一个使用后的自由，或任何其他类型的未定义的行为。

这激发了我的兴趣，理解Python是否可以被视为内存安全，如果是或否，有多安全或不安全？

从一开始，维基百科上的关于记忆安全的文章甚至没有提到Python，关于Python的文章似乎只提到内存管理。我最接近找到答案的是这个是丹尼尔写的

维基百科的文章将类型安全与内存安全联系起来，这意味着同一个内存区域不能以整数和字符串的形式访问。通过这种方式，Python是类型安全的。不能隐式更改对象的类型。

但即便如此，这似乎也只是暗示了两个方面之间的联系(使用维基百科的关联，这同样值得商榷)，对于Python是否可以被视为内存安全的问题，也没有明确的答案。

Answer 1

维基百科列表内存安全问题的以下示例：

Access errors: invalid read/write of a pointer
    Buffer overflow - out-of-bound writes can corrupt the content of adjacent objects, or internal data (like bookkeeping information for the heap) or return addresses.
    Buffer over-read - out-of-bound reads can reveal sensitive data or help attackers bypass address space layout randomization.

Python来防范这些问题。

    Race condition - concurrent reads/writes to shared memory

在具有可变数据结构的语言中，这实际上并不难做到。(函数式编程和不可变数据结构的拥护者经常将这一事实作为对他们有利的论据)。

    Invalid page fault - accessing a pointer outside the virtual memory space. A null pointer dereference will often cause an exception or program termination in most environments, but can cause corruption in operating system kernels or systems without memory protection, or when use of the null pointer involves a large or negative offset.
    Use after free - dereferencing a dangling pointer storing the address of an object that has been deleted.
Uninitialized variables - a variable that has not been assigned a value is used. It may contain an undesired or, in some languages, a corrupt value.
    Null pointer dereference - dereferencing an invalid pointer or a pointer to memory that has not been allocated
    Wild pointers arise when a pointer is used prior to initialization to some known state. They show the same erratic behaviour as dangling pointers, though they are less likely to stay undetected.

没有真正的方法来阻止某人试图访问空指针。在C#和Java中，这将导致一个异常。在C++中，这个导致未定义的行为。

Memory leak - when memory usage is not tracked or is tracked incorrectly
    Stack exhaustion - occurs when a program runs out of stack space, typically because of too deep recursion. A guard page typically halts the program, preventing memory corruption, but functions with large stack frames may bypass the page.

C#、Java和Python等语言中的内存泄漏与您手动管理内存的C和C++等语言中的内存泄漏有不同的含义。在C或C++中，如果未能释放分配的内存，就会导致内存泄漏。在具有托管内存的语言中，您不必显式地去分配内存，但是即使在对象不再需要之后，仍然可以通过意外地维护对某个对象的引用来做类似的事情。

这实际上很容易使用C#中的事件处理程序和长寿命的集合类；尽管我们使用的是托管内存，但我实际上还是在处理存在内存泄漏的项目。从某种意义上说，使用管理内存的环境实际上会使这些问题更加危险，因为程序员可能有错误的安全感。在我的经验中，即使是经验丰富的工程师也常常无法进行内存分析或编写测试用例来检查这一点(可能是因为环境给了他们错误的安全感)。

在Python中，堆栈耗尽也很容易完成(例如，使用无限递归)。

    Heap exhaustion - the program tries to allocate more memory than the amount available. In some languages, this condition must be checked for manually after each allocation.

但还是很有可能的--我很不好意思承认我是用C# (虽然还没有用Python )亲自做过这件事。

    Double free - repeated calls to free may prematurely free a new object at the same address. If the exact address has not been reused, other corruption may occur, especially in allocators that use free lists.
    Invalid free - passing an invalid address to free can corrupt the heap.
    Mismatched free - when multiple allocators are in use, attempting to free memory with a deallocation function of a different allocator[20]
    Unwanted aliasing - when the same memory location is allocated and modified twice for unrelated purposes.

在Python中，不必要的混叠实际上是很容易做到的。这里有一个示例 (完全公开:我编写了公认的答案)；您也可以轻松地在Python中做一些类似的事情。其他的则由Python解释器本身管理。

因此，记忆安全似乎是相对的。具体取决于你认为什么是“内存安全问题”，它实际上很难完全防止。像Java、C#和Python这样的高级语言可以防止这些错误中的许多最糟糕的错误，但是还有其他问题是很难或者不可能完全避免的。