简短答案：
并非如此，在您的情况下恰好为零。
（此外，您的测试用例不会显示数据为零。仅显示一个元素为零的情况。）
长答案：
当您致电时
malloc()，将发生以下两种情况之一：
- 它回收先前分配的内存并从同一进程中释放出来。
- 它从操作系统请求新页面。
在第一种情况下，内存将包含以前分配剩余的数据。因此它不会为零。这是执行小分配时的通常情况。
在第二种情况下，内存将来自操作系统。当程序内存不足时或在请求大量分配时，会发生这种情况。（例如您的示例）
问题在于： 出于 安全 原因，来自操作系统的内存将被清零。*
当操作系统为您提供内存时，它可能已从其他进程中释放出来。这样，内存可以包含敏感信息，例如密码。因此，为防止您读取此类数据，操作系统会在将数据提供给您之前将其清零。
*我注意到C标准对此没有说明。严格来说，这是一种操作系统行为。因此，在不考虑安全性的系统上，可能会或可能不会出现这种调零。
要为此提供更多的性能背景：
作为@R。在评论中提到，此归零是为什么您应始终使用
calloc()而不是
malloc()+的原因
memset()。
calloc()可以利用这个事实来避免单独使用
memset()。
另一方面，这种归零有时是性能瓶颈。在某些数字应用程序中（例如，不适当的FFT），您需要分配大量的暂存存储器。使用它执行任何算法，然后释放它。
在这些情况下，归零是不必要的，并且完全是开销。
我看到的最极端的示例是使用48 GB暂存缓冲区进行70秒的操作需要20秒的清零开销。（大约30％的开销。） （保证：机器确实没有内存带宽。）
显而易见的解决方案是简单地手动重用内存。但这通常需要突破已建立的接口。（特别是如果它是库例程的一部分）
