共计 2936 个字符，预计需要花费 8 分钟才能阅读完成。
但凡 IT 江湖侠士，算法与数据结构为必修之课。早有前辈已经明确指出：程序 = 算法 + 数据结构。要想在之后的江湖历练中通关，数据结构必不可少。数据结构与算法相辅相成，亦是阴阳互补之法。
开篇
说道数组，几乎每个 IT 江湖人士都不陌生，甚至过半人还会很自信觉的它很简单。的确，在菜菜所知道的编程语言中几乎都会有数组的影子。不过它不仅仅是一种基础的数据类型，更是一种基础的数据结构。如果你觉的对数组足够了解，那能不能回答一下：
数组的本质定义？
数组的内存结构？
数组有什么优势？
数组有什么劣势？
数组的应用场景？
数组为什么大部分都从 0 开始编号？
数组能否用其他容器来代替，例如 c# 中的 List<T>？
定义
百科
所谓数组，是相同的元素序列。数组是在程序设计中，为了处理方便，把具有相同类型的若干元素按无序的形式组织起来的一种形式。
正如以上所述，数组在应用上属于数据的容器。不过我还是要补充两点：
数组在数据结构范畴属于一种线性结构，也就是只有前置节点和后续节点的数据结构，除数组之外，像我们平时所用的队列，栈，链表等也都属于线性结构。
有线性结构当然就有非线性结构，比如之后我们要介绍的二叉树，图 等等，这里不再展开~~~
数组元素在内存分配上是连续的。这一点对于数组这种数据结构来说非常重要，甚至可以说是它最大的“杀手锏”。下边会有更详细的介绍。
优势和劣势
优势
我相信所有人在使用数组的时候都知道数组可以按照下标来访问，例如 array[1]。作为一种最基础的数据结构是什么使数组具有这样的随机访问方式呢？天性聪慧的你可能已经想到了：内存连续 + 相同数据类型。现在我们抽象一下数据在内存上分配的情景。
说到数组按下标访问，不得不说一下大多数人的一个“误解”：数组适合查找元素。为什么说是误解呢, 是因为这种说法不够准确，准确的说数组适合按下标来查找元素，而且按照下标查找元素的时间复杂度是 O(1)。为什么呢？我们知道要访问数组的元素需要知道元素在内存中对应的内存地址，而数组指向的内存的地址为首元素的地址，即：array[0]。由于数组的每个元素都是相同的类型，每个类型占用的字节数系统是知道的，所以要想访问一个数组的元素，按照下标查找可以抽象为：
array[n]=array[0]+size*n
以上是元素地址的运算，其中 size 为每个元素的大小，如果为 int 类型数据，那 size 就为 4 个字节。其实确切的说，n 的本质是一个离首元素的偏移量，所以 array[n] 就是距离首元素 n 个偏移量的元素，因此计算 array[n] 的内存地址只需以上公式。
论证一下，如果下标从 1 开始计算，那 array[n] 的内存地址计算公式就会变为：
array[n]=array[0]+size*(n-1)
对比很容易发现，从 1 开始编号比从 0 开始编号每次获取内存地址都多了一次 减法运算，也就多了一次 cpu 指令的运行。这也是数组从 0 下标开始访问一个原因。
其实还有一种可能性，那就是所有现代编程语言的鼻祖：C 语言，它是从 0 开始计数下标的，所以现在所有衍生出来的后代语言也就延续了这个传统。虽然不符合人类的思想，但是符合计算机的原理。当然也有一些语言可以设置为不从下标 0 开始计算，这里不再展开，有兴趣的可以去搜索一下。
由于数组的连续性，所以在遍历数组的时候非常快，不仅得益于数组的连续性，另外也得益于 cpu 的缓存，因为 cpu 读取缓存只能读取连续内存的内容，所以数组的连续性正好符合 cpu 缓存的指令原理，要知道 cpu 缓存的速度要比内存的速度快上很多。
劣势
由于数组在内存排列上是连续的，而且要保持这种连续性，所以当增加一个元素或删除一个元素的时候，为了保证连续性，需要做大量元素的移动工作。
举个栗子：要在数组头部插入一个新元素，为了在头部腾出位置，所有的元素都要后移一位，假设元素个数为 n，这就导致了时间复杂度为 O（n）的一次操作，当然如果是在数组末尾插入新元素，其他所有元素都不必移动，操作的时间复杂度为 O（1）。
当然这里有一个技巧：如果你的业务要求并不是数组连续有序的，当在位置 k 插入元素的时候，只需要把 k 元素转移到数组末尾，新元素插入到 k 位置即可。当然仔细沉思一下这种业务场景可能性太小了，数组都可以无序，我直接插入末尾即可，没有必要非得在 k 位置插入把。~~
当然还有一个特殊场景：如果是多次连续的 k 位置插入操作，我们完全可以合并为一次“批量插入”操作：把 k 之后的元素整体移动 sum（插入次数）个位置，无需一个个位置移动，把三次操作的时间复杂度合并为一次。
与插入对应的就有删除操作，同理，删除操作数组为了保持连续性，也需要元素的移动。
综上所述，数组在添加和删除元素的场景下劣势比较明显，所以在具体业务场景下应该避免频繁添加和删除的操作。
数组的连续性就要求创建数组的时候，内存必须有相应大小的连续区块，如果不存在，数组就有可能出现创建失败的现象。在某些高级语言中（比如 c#，golang，java）就有可能引发一次 GC（垃圾回收）操作，GC 操作在系统运行中是非常昂贵的，有的语言甚至会挂起所有线程的操作，对外的表现就是“暂停服务”。
数组要求所有元素为同一个类型。在存储数据维度，它可能算是一种劣势，但是为了按照下标快速查找元素，业务中这也是一种优势。仁者见仁智者见智而已。
数组是长度固定的数据结构，所以在原始数组的基础上扩容是不可能的，有的语言可能实现数组的“伪扩容”，为什么说是“伪”呢，因为原理其实是创建了一个容量更大的数组来存放原数组元素，发生了数据复制的过程，只不过对于调用者而已透明而已。
数组有访问越界的可能。我们按照下标访问数组的时候如果下标超出了数组长度，在现代多数高级语言中，直接就会引发异常了，但是一些低级语言比如 C 有可能会访问到数组元素以外的数据，因为要访问的内存地址确实存在。
其他
很多编程语言中你会发现“纯数组”并没有提供直接删除元素的方法（例如：c#，golang），而是需要将数组转化为另一种数据结构来实现数组元素的删除。比如在 golang 种可以转化为 slice。这也验证了数组的不变性。
应用场景
我们学习的每个数据结构其实都有对应的适合场景，只不过是场景多少的问题，具体什么时候用，需要我们对该数据结构的特性做深入分析。关于数组的特性，通过以上介绍可以知道最大的一个亮点就是按照下标访问，那有没有具体业务映射这种特性呢？
相信很多 IT 人士都遇到过会员机制，每个会员到达一定的经验值就会升级，怎么判断当前的经验是否到达升级条件呢？我们是不是可以这样做：比如当前会员等级为 3，判断是否到达等级 4 的经验值，只需要 array[4] 的值判断即可，大多数人把配置放到 DB，资源耗费太严重。也有的人放到其他容器缓存。但是大部分场景下查询的时间复杂度要比数组大很多。
在分布式底层应用中，我们会有利用一致性哈希方案来解决每个请求交给哪个服务器去处理的场景。有兴趣的同学可以自己去研究一下。其中有一个环节：根据哈希值查找对应的服务器，这是典型的读多写少的应用，而且比较偏底层。如果用其他数据结构来解决大量的查找问题，可能会触碰到性能的瓶颈。而数据按下标访问时间复杂度为 O(1) 的特性，使得数组在类似这些应用中非常广泛。
添加关注，查看更精美版本，收获更多精彩
