很多Java教程走到第11天都会让你写一个学生管理系统。我第一次写这个项目时第一个反应是用数组存学生不就行了吗但真到动手才发现数组的几个基本操作——增、删、改、查每一件事做起来都很别扭。后来换成了ArrayList整个代码一下子清爽了。这篇文章就围绕day11-ArrayList学生管理系统这个教学节点把ArrayList的原理、扩容机制、系统设计思路和一些藏在细节里的坑一次说清楚。内容适合正在学Java集合的初学者也适合已经会用ArrayList但没深究过底层的人。我会从为什么选ArrayList开始逐步拆到源码级扩容机制再到一个完整管理系统的增删改查实现最后提几个实战中很隐蔽的坑。全程用代码和对比说话尽量不绕弯子。1. 学生管理系统为什么非得学ArrayList——从数组的硬伤说起1.1 数组长度固定学生人数是动态的数组是静态的学生管理系统的第一个需求就是能添加学生。可数组从声明那一刻起长度就不能变了。你说开一个Student[100]那如果第101个学生来报到怎么办你说开Student[10000]那大部分情况下这1万个坑位有一大半是空的内存白占着程序还显得很笨重。有人会想那我每次添加学生的时候重新new一个更长的数组把旧数据拷贝过去行不行技术上当然行代码写出来大概是这个样子Student[] oldArr new Student[10]; // 假设已经存了10个学生 Student[] newArr Arrays.copyOf(oldArr, oldArr.length 1); newArr[newArr.length - 1] newStudent; oldArr newArr;这段代码看着不复杂但次数一多问题就来了首先是代码里到处是数组搬运的细节逻辑被怎么存淹没而不是聚焦存了什么其次是我每加一个学生就要搬一次家数据少还好数据一多性能会有明显浪费。更重要的是删除学生更麻烦——你要把被删元素后面的所有元素整体往前挪一位同时还得处理末尾那个残留引用。这种手工操作极其容易出错而且出错之后极难定位。数组还有一个隐藏问题它的天然定位是固定长度的连续存储。但在学生管理这个真实场景里今天3个人、明天5个人、后天可能退学1个人才是常态。用数组这种静态结构去描述动态数据本身就存在结构不匹配的问题。所以几乎所有教学项目走到这一步都会自然引出集合这个概念。1.2 ArrayList补上了什么动态扩容与封装后的操作APIArrayList在中文里经常被叫作动态数组。你可以把它理解成一个会自动长大的数组底层确实是数组但它帮你把装满了怎么办这件事内部处理掉了。它和数组的核心区别一是容量可自动增长二是提供了丰富的操作方法。拿写学生管理系统来说用ArrayList之后添加一个学生就一行代码list.add(student);删除一个学生如果是按下标删就一行list.remove(index);判断某个学号是否存在不用自己写循环遍历直接用boolean exists list.contains(target);这些API用起来确实省事但我要提醒一点省事是建立在封装之上的封装背后仍然是下标移动、数组拷贝这些老逻辑。如果只停留在会调用API后面系统一旦复杂起来很容易写出盲目操作。比如有人习惯反复add而不知道ArrayList会自动扩容也不关心扩容的代价有人频繁在中间位置插入导致大量元素反复搬家。这些问题的根源都是缺少对底层机制的理解。ArrayList还有点很讨喜它保持了数组随机访问快的优点。list.get(3)和arr[3]一样都是根据下标直接计算内存地址时间复杂度是O(1)。这一点是后面要讲的LinkedList比不了的。通俗点说ArrayList像一支编好号的队伍你说第5个人出列点一下就行而LinkedList更像手拉手的一串人你说第5个人出列得从第1个开始一个个数过去。所以学生管理系统选ArrayList并不只是因为简单而是因为它的动态扩容能力、随机访问特性、以及丰富的API和学生人数会变、经常按下标/学号操作、数据量不大这个场景高度匹配。理解到这一层后面写代码才不会被用哪个集合这个问题反复卡住。2. ArrayList扩容机制源码级拆解它到底是怎么长大的2.1 三个构造方法与首次add的扩容触发路径先看一个非常核心又常被忽略的问题new ArrayList()创建出来之后底层数组真的是空数组吗答案是真的空。在JDK 8及之后的版本里无参构造会直接指向一个共享的空数组DEFAULTCAPACITY_EMPTY_ELEMENTDATAprivate static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA {}; public ArrayList() { this.elementData DEFAULTCAPACITY_EMPTY_ELEMENTDATA; }也就是说刚创建出来的ArrayList内部数组长度是0不是很多人以为的10。那默认容量10这个说法是哪来的当你第一次add元素的时候才懒加载add会先调用ensureCapacityInternal发现当前数组还是那个空数组就先把minCapacity取成Math.max(DEFAULT_CAPACITY, 传入的size1)其中DEFAULT_CAPACITY 10。也就是说第一次add时扩容的目标至少是10所以第一个元素加进来之后数组长度变成了10。如果你用带初始容量的构造new ArrayList(20);那底层会直接new Object[20]不会走懒加载。这个初始容量怎么选后面我会详细说这里先记住结论如果你大概知道要存多少数据优先给一个合理初始值能省掉好几轮扩容。真正干活的方法是grow(int minCapacity)。JDK 8里扩容的关键代码逻辑是int oldCapacity elementData.length; int newCapacity oldCapacity (oldCapacity 1); if (newCapacity - minCapacity 0) { newCapacity minCapacity; } elementData Arrays.copyOf(elementData, newCapacity);oldCapacity 1是右移一位等价于除以2。所以新容量等于旧容量加旧容量的一半也就是1.5倍扩容。比如数组从10个容量扩到15个再扩到22个再扩到33个依此类推。扩容的具体操作是Arrays.copyOf本质是新建一个更大的数组把旧数组的元素一个个拷贝过去然后让elementData指向新数组。2.2 1.5倍扩容倍率背后的折中逻辑与容量估算技巧为什么偏偏是1.5倍而不是2倍也不是1.1倍这背后是一个经典的工程折中问题。如果扩容太猛比如翻倍再翻倍那内存浪费很严重——你实际只存12个元素底层数组可能已经扩容到30了。如果扩容太保守比如每次只增加10个那插入频繁的时候会反复触发数组复制时间上吃不消。1.5倍这个比例能让扩容次数控制在对数级。我们看个具体例子从容量10开始扩到15、22、33、49、73、109……你每多存一个数据数组就悄悄长大一半。这样既不会疯狂搬家也不会一次性多出太多浪费空间。实际上Java官方在性能测试中验证过1.5倍属于空间和时间比较均衡的选择类似的思想在很多动态数组实现里都能看到比如某些语言里的向量容器采用1.5倍或2倍策略。这里有个很实用的经验容量估算宁多勿少但别离谱。如果你知道学生系统最多可能存500人直接new ArrayList(500)比用默认容量从10一路扩到500要省下好几轮Arrays.copyOf。虽然对学生管理系统这种小项目来说性能差异微乎其微但面试里经常问写代码时的习惯也能体现一个程序员对底层开销的敏感度。再补充一个容易被忽略的点Arrays.copyOf增容之后旧数组中多余位置的引用还在吗其实已经不在了因为copyOf只拷贝Math.min(original.length, newLength)个元素新数组多出来的空间全部是null。所以扩容本身不会造成旧引用不释放的问题但如果你把一个巨大的ArrayList清空后还留着引用那底层大数组依然是占着内存的。list.clear()只是把所有元素置为null并不会把数组缩回默认大小。这种细节在实际业务中偶尔会碰到一个长时间运行的进程里ArrayList高峰期占了超大容量之后数据清空了但内存峰值下不去。真要解决可以对ArrayList做一次缩容重建或者重新new一个列表来替代它。3. 管理系统的地基Student类与增删改查方法设计3.1 实体类这么写才不容易在后面踩坑学生管理系统的数据载体是学生。这个类设计得好不好直接决定后面所有功能的写法和踩坑概率。一个标准的学生实体最少应该包含学号、姓名、年龄扩展一点可以加班级、专业等。我比较推荐一开始就养成写实体类的规范习惯public class Student { private String id; private String name; private int age; private String className; public Student(String id, String name, int age, String className) { this.id id; this.name name; this.age age; this.className className; } public String getId() { return id; } public void setId(String id) { this.id id; } public String getName() { return name; } public void setName(String name) { this.name name; } public int getAge() { return age; } public void setAge(int age) { this.age age; } public String getClassName() { return className; } public void setClassName(String className) { this.className className; } Override public String toString() { return Student{id id , name name , age age , className className }; } Override public boolean equals(Object o) { if (this o) return true; if (!(o instanceof Student)) return false; Student s (Student) o; return Objects.equals(id, s.id) Objects.equals(name, s.name); } Override public int hashCode() { return Objects.hash(id, name); } }很多人写实体类只写getter/setter和toString觉得equals无所谓。等到系统里要用contains判断某个学生是否已存在或者用indexOf查找学生下标的时候才发现行为完全不符合预期。ArrayList里的contains、indexOf、remove(Object)全靠equals来判定相等如果你不重写它默认比较的是两个对象的地址引用。也就是说即使两个学生的学号、姓名完全一样只要它们是new出来的两个不同对象contains依然会返回false。重写equals的同时务必重写hashCode这不是形式主义。因为ArrayList虽然不依赖hashCode但后续把学生对象放进HashSet、HashMap这类集合时hashCode不一致会导致对象看起来相等却存不进去。提前把这两个方法写好是给未来省麻烦。还有一点equals的判定字段要想清楚。学生管理系统里学号是天然的唯一下标识所以equals里至少要比学号。如果你把年龄也算进equals那同一个学生只要年龄改一岁就会被判定成两个不同的人这在业务上显然是错的。所以业务字段的选择比写代码本身更重要。3.2 学生集合的增删改查每一行代码都有讲究有了Student类接下来就是用ArrayList实现增删改查。我建议不要直接在main方法里堆逻辑而是把对集合的操作封装成方法这样代码好读也好复用。下面是一个典型的操作封装public class StudentManager { private ArrayListStudent students new ArrayList(); // 添加学生 public boolean addStudent(Student s) { if (containsById(s.getId())) { System.out.println(学号已存在 s.getId()); return false; } students.add(s); return true; } // 按学号判断是否存在 public boolean containsById(String id) { for (Student s : students) { if (s.getId().equals(id)) { return true; } } return false; } // 删除学生按学号 public boolean removeById(String id) { for (int i 0; i students.size(); i) { if (students.get(i).getId().equals(id)) { students.remove(i); return true; } } return false; } // 修改学生年龄 public boolean updateAge(String id, int newAge) { for (Student s : students) { if (s.getId().equals(id)) { s.setAge(newAge); return true; } } return false; } // 查看所有学生 public void printAll() { if (students.isEmpty()) { System.out.println(暂无学生数据); return; } for (Student s : students) { System.out.println(s); } } }这段代码里有一个细节值得多说两句。添加学生时我做了学号重复校验这是真实管理系统的基本要求。很多初学者不加这一层结果系统里出现两个同号的学生后面改数据和删数据都分不清该操作谁。虽然ArrayList本身允许重复元素但业务上不允许所以校验逻辑必须在操作之前挡上一道。删除按下标还是按对象这里我选择按下标删先遍历找到匹配学号的下标再remove(i)。为什么不直接用remove(student)一是需要提前构造一个对象二是你还得依赖equals的字段设计。下标删在集合元素不多时非常直观时间复杂度也是O(n)因为遍历本身就要扫一遍。修改操作的思路跟删除类似先用学号定位再通过setter更新字段。这里有个隐藏优势ArrayList里存的是对象的引用你拿到Student s之后直接s.setAge(newAge)集合里的对象就跟着变了不需要再set(index, newStudent)。很多人刚学的时候不理解为什么我改了slist里也变了因为list里存的不是对象的副本而是指向堆内存中同一个对象的引用。最后是打印。System.out.println(s)会自动调用s.toString()所以实体类的toString一定认真写别输出一串Student1f32e575这种内存地址。看到那种输出先检查是不是没有重写toString。4. 增删改查之外三个一旦踩中就要排查半天的坑4.1 遍历时删除元素索引错位是怎么发生的这是新手写学生管理系统最容易踩的坑而且踩了之后往往一脸懵。需求很简单把班里所有姓王的学生删掉。直觉写法是这样的for (int i 0; i list.size(); i) { if (list.get(i).getName().startsWith(王)) { list.remove(i); } }跑一下会发现总有姓王的学生被漏掉。原因是删除元素后后面的元素会集体往前挪一位当前下标i已经被下一个元素占据了可循环里的i又把下标往后推了一位相当于跳过一个元素没检查。比如第3个位置删掉一个人原来的第4个人挪到了第3位但下一次循环直接去检查第4位了他完美地躲过了检查。解决方案有几种。最基础、最容易理解的是倒序遍历for (int i list.size() - 1; i 0; i--) { if (list.get(i).getName().startsWith(王)) { list.remove(i); } }倒着删时删除某个元素只会影响它后面的元素而后面那些元素已经被检查过了前面没被检查的元素位置不会变。第二种是用迭代器的remove方法IteratorStudent it list.iterator(); while (it.hasNext()) { Student s it.next(); if (s.getName().startsWith(王)) { it.remove(); } }it.remove()会删除当前遍历到的元素并且迭代器内部会维护一个预期修改次数不会出现下标错位。第三种是JDK 8提供的removeIf本质上是迭代器方案的语法糖list.removeIf(s - s.getName().startsWith(王));用removeIf最简洁一行搞定。我个人的建议是优先掌握倒序遍历因为它能帮你理解集合操作的本质日常写代码用removeIf因为它意图清晰且不易出错。推荐用增强for循环去一边遍历一边删除那样会直接抛ConcurrentModificationException很多新手看到这个异常完全不知道发生了什么。顺带说明ConcurrentModificationException是ArrayList的modCount机制在起作用。每次结构性修改add/remove都会增加modCount迭代器初始化时保存了当时的modCount每次调用next()都会检查当前值是否一致不一致就立刻抛异常。这个设计本质上是快速失败机制目的是及时暴露并发修改问题避免在脏数据上继续运行。4.2 contains为什么不认识内容相同的学生再来看一个调试起来特别隐蔽的问题。假设你写了一个功能录入新生之前先检查学号是否被占用了。你没有自己写遍历而是用了现成的APIStudent tmp new Student(1001, 张三, 18, 计算机1班); if (students.contains(tmp)) { System.out.println(学号已存在); }理论上应该提示学号已存在但程序却把同一个学号的学生加进去了两次。为什么因为contains调用的是元素的equals方法而你没有重写Student.equals于是它比较的是两个对象的引用地址。students里的 1001张三 和刚刚new出来的 1001张三 是两个完全不同的对象地址不一样equals返回falsecontains自然返回false。这个坑最难受的地方在于代码看起来没有任何报错逻辑也符合直觉可结果就是不对。等你意识到是equals的问题时可能已经排查了很久。排查方法很简单在Student类里重写equals然后contains立刻恢复正常Override public boolean equals(Object o) { if (this o) return true; if (!(o instanceof Student)) return false; Student s (Student) o; return Objects.equals(id, s.id); }注意这里我只用学号判定相等因为学号在业务上唯一。如果你把姓名和年龄也加进去那同一个学生修改过年龄之后contains就有可能判定不相等这在学生管理场景里很容易出逻辑漏洞。equals里放哪些字段应该由业务唯一性决定而不是把所有字段都写上。4.3 泛型偷懒的代价类型擦除与ClassCastException很多教材会提一句ArrayList如果不写泛型默认就是ArrayListObject什么都能往里扔。有人图省事真的这么干ArrayList list new ArrayList(); list.add(new Student(1001, 张三, 18, 计算机1班)); list.add(这是一个字符串);等到遍历取数据时你记得里面全是Student于是强转Student s (Student) list.get(1);这句代码会直接抛ClassCastException因为第2个元素其实是个String强转当然失败。这种错误在编译期完全发现不了等到运行才炸而且炸的时候往往和实际入坑的代码隔得很远排查成本很高。写上行规的泛型之后编译器会在你做add时检查类型取出来也不用强转ArrayListStudent list new ArrayList(); list.add(new Student(...)); // 类型不对根本编译不过 Student s list.get(0); // 不用强转这里有一个值得展开的背景知识Java的泛型是类型擦除的泛型信息只存在于编译期运行时ArrayList并不知道自己存的是什么类型。你写成ArrayListStudent编译后字节码里还是ArrayListObject但编译器已经在入口处插入了类型检查在读取处插入了隐式强转。IDE报红、编译报错都是这个编译期防火墙在起作用。在写学生管理系统时我强烈建议从一开始就写满泛型不要偷这个懒。你可能觉得反正我存的全是Student但人总有失误的时候让编译器帮你把关成本最低。另外如果你用的是Java 7及以上new ArrayList()后面的尖括号可以不写类型通过类型推断自动补齐代码更干净。5. 把整个系统串起来主菜单循环与后续扩展方向5.1 一个清晰可控的主流程长什么样前面的Student类和管理方法都准备好了最后一步是把它们拼成一个能跑起来的系统。学生管理系统一般用控制台交互核心是一个主菜单循环显示菜单、接收用户输入、根据选择执行操作、回到菜单。这里直接给一个骨架public static void main(String[] args) { StudentManager manager new StudentManager(); Scanner sc new Scanner(System.in); while (true) { System.out.println( 学生管理系统 ); System.out.println(1. 添加学生); System.out.println(2. 删除学生); System.out.println(3. 修改学生信息); System.out.println(4. 查看所有学生); System.out.println(5. 退出系统); System.out.print(请选择操作); int choice sc.nextInt(); sc.nextLine(); // 吸收掉换行符 switch (choice) { case 1: System.out.print(请输入学号); String id sc.nextLine(); System.out.print(请输入姓名); String name sc.nextLine(); // 为了演示年龄在这里直接给0正式代码应sc.nextInt() Student s new Student(id, name, 0, 待定班级); manager.addStudent(s); break; case 2: System.out.print(请输入要删除的学号); String delId sc.nextLine(); manager.removeById(delId); break; // case 3, case 4 同理 case 5: System.out.println(系统已退出); return; default: System.out.println(无效选项请重新输入); } } }这个骨架里有几个值得注意的细节。第一个是sc.nextInt()后面的sc.nextLine()nextInt只读取了数字会把数字后面的换行符留在输入缓冲区里如果之后再用nextLine读取字符串就会直接读到那个空行导致输入一个学号结果没反应。这个坑极其常见处理方式就是吃一个多余的换行。第二个是无限循环加return退出。这种写法在控制台交互里没问题因为程序的生命周期就是靠这个循环维持的。写成System.exit(0)也可以但return更加直观代码阅读者一看就知道是结束整个main方法。第三个是默认分支。如果用户输入了超出1~5的选项一定要有default兜底提示重新输入否则switch会什么也不做就回到菜单。看起来是小细节但对用户体验影响很大。我给这段代码里的年龄用0做演示值是因为要先把主流程跑通再加细节。先让系统动起来再逐步完善输入校验、异常处理和字段必填检查是写控制台项目非常实用的一个策略。很多初学者一上来就想把所有输入都做完美校验结果卡在细节里迟迟看不到程序的完整效果反而容易丧失信心。5.2 当数据量变大之后ArrayList还够用吗学生管理系统做完有好奇心的同学可能会问现在学生几十个、几百个ArrayList完全没问题。但如果数据量变成几万、几十万呢是不是还够用要分情况看。如果操作主要是按后缀追加学生和按索引查看ArrayList依然高效因为尾部添加和按下标访问都是O(1)。但有两个场景ArrayList会变得吃力第一个是频繁在中间位置插入或删除。比如按照学号有序插入这种需求每次插入都要让后续元素整体后移平均时间复杂度O(n)。数据少无感数据多了性能下降非常明显。这种场景更适合LinkedList它虽然随机访问慢但在已知节点的前提下插入删除是O(1)。第二个是频繁按某个非索引字段查找。ArrayList的查找只能线性遍历O(n)从头扫到尾。学生管理系统里按学号查找、按姓名模糊查询数据规模大了之后每条查询都要扫全表。这时就会自然引出哈希表的思想——按学号直接算出存储位置查询变成O(1)。这也就是后面学习HashMap的动机。从这个角度看学生管理系统虽然是个入门项目但它的价值不只是练习语法而是让你亲手体会不同数据结构适合不同场景。ArrayList解决了动态数组的问题但它不是银弹。当你真正理解了课程里那句数据结构的选择决定算法效率再回头看这个系统就知道下一步该学什么了。我在实际写这类教学项目时还有一种体会纸上谈兵远远不够代码写出来跑一遍再在调试器里观察变量和底层数组的变化这部分才算真正过脑了。建议你用IDE的调试模式在grow方法附近打断点观察ArrayList底层数组长度一次次从10变成15、15变成22或者在删除元素时亲眼看后续元素往前挪的过程。今天这篇讲的扩容机制、索引错位、equals判定全都可以在调试器里得到验证跑通一遍之后你对ArrayList的理解会扎实很多。
从数组到ArrayList：学生管理系统背后的动态扩容与增删改查深度解析
很多Java教程走到第11天都会让你写一个学生管理系统。我第一次写这个项目时第一个反应是用数组存学生不就行了吗但真到动手才发现数组的几个基本操作——增、删、改、查每一件事做起来都很别扭。后来换成了ArrayList整个代码一下子清爽了。这篇文章就围绕day11-ArrayList学生管理系统这个教学节点把ArrayList的原理、扩容机制、系统设计思路和一些藏在细节里的坑一次说清楚。内容适合正在学Java集合的初学者也适合已经会用ArrayList但没深究过底层的人。我会从为什么选ArrayList开始逐步拆到源码级扩容机制再到一个完整管理系统的增删改查实现最后提几个实战中很隐蔽的坑。全程用代码和对比说话尽量不绕弯子。1. 学生管理系统为什么非得学ArrayList——从数组的硬伤说起1.1 数组长度固定学生人数是动态的数组是静态的学生管理系统的第一个需求就是能添加学生。可数组从声明那一刻起长度就不能变了。你说开一个Student[100]那如果第101个学生来报到怎么办你说开Student[10000]那大部分情况下这1万个坑位有一大半是空的内存白占着程序还显得很笨重。有人会想那我每次添加学生的时候重新new一个更长的数组把旧数据拷贝过去行不行技术上当然行代码写出来大概是这个样子Student[] oldArr new Student[10]; // 假设已经存了10个学生 Student[] newArr Arrays.copyOf(oldArr, oldArr.length 1); newArr[newArr.length - 1] newStudent; oldArr newArr;这段代码看着不复杂但次数一多问题就来了首先是代码里到处是数组搬运的细节逻辑被怎么存淹没而不是聚焦存了什么其次是我每加一个学生就要搬一次家数据少还好数据一多性能会有明显浪费。更重要的是删除学生更麻烦——你要把被删元素后面的所有元素整体往前挪一位同时还得处理末尾那个残留引用。这种手工操作极其容易出错而且出错之后极难定位。数组还有一个隐藏问题它的天然定位是固定长度的连续存储。但在学生管理这个真实场景里今天3个人、明天5个人、后天可能退学1个人才是常态。用数组这种静态结构去描述动态数据本身就存在结构不匹配的问题。所以几乎所有教学项目走到这一步都会自然引出集合这个概念。1.2 ArrayList补上了什么动态扩容与封装后的操作APIArrayList在中文里经常被叫作动态数组。你可以把它理解成一个会自动长大的数组底层确实是数组但它帮你把装满了怎么办这件事内部处理掉了。它和数组的核心区别一是容量可自动增长二是提供了丰富的操作方法。拿写学生管理系统来说用ArrayList之后添加一个学生就一行代码list.add(student);删除一个学生如果是按下标删就一行list.remove(index);判断某个学号是否存在不用自己写循环遍历直接用boolean exists list.contains(target);这些API用起来确实省事但我要提醒一点省事是建立在封装之上的封装背后仍然是下标移动、数组拷贝这些老逻辑。如果只停留在会调用API后面系统一旦复杂起来很容易写出盲目操作。比如有人习惯反复add而不知道ArrayList会自动扩容也不关心扩容的代价有人频繁在中间位置插入导致大量元素反复搬家。这些问题的根源都是缺少对底层机制的理解。ArrayList还有点很讨喜它保持了数组随机访问快的优点。list.get(3)和arr[3]一样都是根据下标直接计算内存地址时间复杂度是O(1)。这一点是后面要讲的LinkedList比不了的。通俗点说ArrayList像一支编好号的队伍你说第5个人出列点一下就行而LinkedList更像手拉手的一串人你说第5个人出列得从第1个开始一个个数过去。所以学生管理系统选ArrayList并不只是因为简单而是因为它的动态扩容能力、随机访问特性、以及丰富的API和学生人数会变、经常按下标/学号操作、数据量不大这个场景高度匹配。理解到这一层后面写代码才不会被用哪个集合这个问题反复卡住。2. ArrayList扩容机制源码级拆解它到底是怎么长大的2.1 三个构造方法与首次add的扩容触发路径先看一个非常核心又常被忽略的问题new ArrayList()创建出来之后底层数组真的是空数组吗答案是真的空。在JDK 8及之后的版本里无参构造会直接指向一个共享的空数组DEFAULTCAPACITY_EMPTY_ELEMENTDATAprivate static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA {}; public ArrayList() { this.elementData DEFAULTCAPACITY_EMPTY_ELEMENTDATA; }也就是说刚创建出来的ArrayList内部数组长度是0不是很多人以为的10。那默认容量10这个说法是哪来的当你第一次add元素的时候才懒加载add会先调用ensureCapacityInternal发现当前数组还是那个空数组就先把minCapacity取成Math.max(DEFAULT_CAPACITY, 传入的size1)其中DEFAULT_CAPACITY 10。也就是说第一次add时扩容的目标至少是10所以第一个元素加进来之后数组长度变成了10。如果你用带初始容量的构造new ArrayList(20);那底层会直接new Object[20]不会走懒加载。这个初始容量怎么选后面我会详细说这里先记住结论如果你大概知道要存多少数据优先给一个合理初始值能省掉好几轮扩容。真正干活的方法是grow(int minCapacity)。JDK 8里扩容的关键代码逻辑是int oldCapacity elementData.length; int newCapacity oldCapacity (oldCapacity 1); if (newCapacity - minCapacity 0) { newCapacity minCapacity; } elementData Arrays.copyOf(elementData, newCapacity);oldCapacity 1是右移一位等价于除以2。所以新容量等于旧容量加旧容量的一半也就是1.5倍扩容。比如数组从10个容量扩到15个再扩到22个再扩到33个依此类推。扩容的具体操作是Arrays.copyOf本质是新建一个更大的数组把旧数组的元素一个个拷贝过去然后让elementData指向新数组。2.2 1.5倍扩容倍率背后的折中逻辑与容量估算技巧为什么偏偏是1.5倍而不是2倍也不是1.1倍这背后是一个经典的工程折中问题。如果扩容太猛比如翻倍再翻倍那内存浪费很严重——你实际只存12个元素底层数组可能已经扩容到30了。如果扩容太保守比如每次只增加10个那插入频繁的时候会反复触发数组复制时间上吃不消。1.5倍这个比例能让扩容次数控制在对数级。我们看个具体例子从容量10开始扩到15、22、33、49、73、109……你每多存一个数据数组就悄悄长大一半。这样既不会疯狂搬家也不会一次性多出太多浪费空间。实际上Java官方在性能测试中验证过1.5倍属于空间和时间比较均衡的选择类似的思想在很多动态数组实现里都能看到比如某些语言里的向量容器采用1.5倍或2倍策略。这里有个很实用的经验容量估算宁多勿少但别离谱。如果你知道学生系统最多可能存500人直接new ArrayList(500)比用默认容量从10一路扩到500要省下好几轮Arrays.copyOf。虽然对学生管理系统这种小项目来说性能差异微乎其微但面试里经常问写代码时的习惯也能体现一个程序员对底层开销的敏感度。再补充一个容易被忽略的点Arrays.copyOf增容之后旧数组中多余位置的引用还在吗其实已经不在了因为copyOf只拷贝Math.min(original.length, newLength)个元素新数组多出来的空间全部是null。所以扩容本身不会造成旧引用不释放的问题但如果你把一个巨大的ArrayList清空后还留着引用那底层大数组依然是占着内存的。list.clear()只是把所有元素置为null并不会把数组缩回默认大小。这种细节在实际业务中偶尔会碰到一个长时间运行的进程里ArrayList高峰期占了超大容量之后数据清空了但内存峰值下不去。真要解决可以对ArrayList做一次缩容重建或者重新new一个列表来替代它。3. 管理系统的地基Student类与增删改查方法设计3.1 实体类这么写才不容易在后面踩坑学生管理系统的数据载体是学生。这个类设计得好不好直接决定后面所有功能的写法和踩坑概率。一个标准的学生实体最少应该包含学号、姓名、年龄扩展一点可以加班级、专业等。我比较推荐一开始就养成写实体类的规范习惯public class Student { private String id; private String name; private int age; private String className; public Student(String id, String name, int age, String className) { this.id id; this.name name; this.age age; this.className className; } public String getId() { return id; } public void setId(String id) { this.id id; } public String getName() { return name; } public void setName(String name) { this.name name; } public int getAge() { return age; } public void setAge(int age) { this.age age; } public String getClassName() { return className; } public void setClassName(String className) { this.className className; } Override public String toString() { return Student{id id , name name , age age , className className }; } Override public boolean equals(Object o) { if (this o) return true; if (!(o instanceof Student)) return false; Student s (Student) o; return Objects.equals(id, s.id) Objects.equals(name, s.name); } Override public int hashCode() { return Objects.hash(id, name); } }很多人写实体类只写getter/setter和toString觉得equals无所谓。等到系统里要用contains判断某个学生是否已存在或者用indexOf查找学生下标的时候才发现行为完全不符合预期。ArrayList里的contains、indexOf、remove(Object)全靠equals来判定相等如果你不重写它默认比较的是两个对象的地址引用。也就是说即使两个学生的学号、姓名完全一样只要它们是new出来的两个不同对象contains依然会返回false。重写equals的同时务必重写hashCode这不是形式主义。因为ArrayList虽然不依赖hashCode但后续把学生对象放进HashSet、HashMap这类集合时hashCode不一致会导致对象看起来相等却存不进去。提前把这两个方法写好是给未来省麻烦。还有一点equals的判定字段要想清楚。学生管理系统里学号是天然的唯一下标识所以equals里至少要比学号。如果你把年龄也算进equals那同一个学生只要年龄改一岁就会被判定成两个不同的人这在业务上显然是错的。所以业务字段的选择比写代码本身更重要。3.2 学生集合的增删改查每一行代码都有讲究有了Student类接下来就是用ArrayList实现增删改查。我建议不要直接在main方法里堆逻辑而是把对集合的操作封装成方法这样代码好读也好复用。下面是一个典型的操作封装public class StudentManager { private ArrayListStudent students new ArrayList(); // 添加学生 public boolean addStudent(Student s) { if (containsById(s.getId())) { System.out.println(学号已存在 s.getId()); return false; } students.add(s); return true; } // 按学号判断是否存在 public boolean containsById(String id) { for (Student s : students) { if (s.getId().equals(id)) { return true; } } return false; } // 删除学生按学号 public boolean removeById(String id) { for (int i 0; i students.size(); i) { if (students.get(i).getId().equals(id)) { students.remove(i); return true; } } return false; } // 修改学生年龄 public boolean updateAge(String id, int newAge) { for (Student s : students) { if (s.getId().equals(id)) { s.setAge(newAge); return true; } } return false; } // 查看所有学生 public void printAll() { if (students.isEmpty()) { System.out.println(暂无学生数据); return; } for (Student s : students) { System.out.println(s); } } }这段代码里有一个细节值得多说两句。添加学生时我做了学号重复校验这是真实管理系统的基本要求。很多初学者不加这一层结果系统里出现两个同号的学生后面改数据和删数据都分不清该操作谁。虽然ArrayList本身允许重复元素但业务上不允许所以校验逻辑必须在操作之前挡上一道。删除按下标还是按对象这里我选择按下标删先遍历找到匹配学号的下标再remove(i)。为什么不直接用remove(student)一是需要提前构造一个对象二是你还得依赖equals的字段设计。下标删在集合元素不多时非常直观时间复杂度也是O(n)因为遍历本身就要扫一遍。修改操作的思路跟删除类似先用学号定位再通过setter更新字段。这里有个隐藏优势ArrayList里存的是对象的引用你拿到Student s之后直接s.setAge(newAge)集合里的对象就跟着变了不需要再set(index, newStudent)。很多人刚学的时候不理解为什么我改了slist里也变了因为list里存的不是对象的副本而是指向堆内存中同一个对象的引用。最后是打印。System.out.println(s)会自动调用s.toString()所以实体类的toString一定认真写别输出一串Student1f32e575这种内存地址。看到那种输出先检查是不是没有重写toString。4. 增删改查之外三个一旦踩中就要排查半天的坑4.1 遍历时删除元素索引错位是怎么发生的这是新手写学生管理系统最容易踩的坑而且踩了之后往往一脸懵。需求很简单把班里所有姓王的学生删掉。直觉写法是这样的for (int i 0; i list.size(); i) { if (list.get(i).getName().startsWith(王)) { list.remove(i); } }跑一下会发现总有姓王的学生被漏掉。原因是删除元素后后面的元素会集体往前挪一位当前下标i已经被下一个元素占据了可循环里的i又把下标往后推了一位相当于跳过一个元素没检查。比如第3个位置删掉一个人原来的第4个人挪到了第3位但下一次循环直接去检查第4位了他完美地躲过了检查。解决方案有几种。最基础、最容易理解的是倒序遍历for (int i list.size() - 1; i 0; i--) { if (list.get(i).getName().startsWith(王)) { list.remove(i); } }倒着删时删除某个元素只会影响它后面的元素而后面那些元素已经被检查过了前面没被检查的元素位置不会变。第二种是用迭代器的remove方法IteratorStudent it list.iterator(); while (it.hasNext()) { Student s it.next(); if (s.getName().startsWith(王)) { it.remove(); } }it.remove()会删除当前遍历到的元素并且迭代器内部会维护一个预期修改次数不会出现下标错位。第三种是JDK 8提供的removeIf本质上是迭代器方案的语法糖list.removeIf(s - s.getName().startsWith(王));用removeIf最简洁一行搞定。我个人的建议是优先掌握倒序遍历因为它能帮你理解集合操作的本质日常写代码用removeIf因为它意图清晰且不易出错。推荐用增强for循环去一边遍历一边删除那样会直接抛ConcurrentModificationException很多新手看到这个异常完全不知道发生了什么。顺带说明ConcurrentModificationException是ArrayList的modCount机制在起作用。每次结构性修改add/remove都会增加modCount迭代器初始化时保存了当时的modCount每次调用next()都会检查当前值是否一致不一致就立刻抛异常。这个设计本质上是快速失败机制目的是及时暴露并发修改问题避免在脏数据上继续运行。4.2 contains为什么不认识内容相同的学生再来看一个调试起来特别隐蔽的问题。假设你写了一个功能录入新生之前先检查学号是否被占用了。你没有自己写遍历而是用了现成的APIStudent tmp new Student(1001, 张三, 18, 计算机1班); if (students.contains(tmp)) { System.out.println(学号已存在); }理论上应该提示学号已存在但程序却把同一个学号的学生加进去了两次。为什么因为contains调用的是元素的equals方法而你没有重写Student.equals于是它比较的是两个对象的引用地址。students里的 1001张三 和刚刚new出来的 1001张三 是两个完全不同的对象地址不一样equals返回falsecontains自然返回false。这个坑最难受的地方在于代码看起来没有任何报错逻辑也符合直觉可结果就是不对。等你意识到是equals的问题时可能已经排查了很久。排查方法很简单在Student类里重写equals然后contains立刻恢复正常Override public boolean equals(Object o) { if (this o) return true; if (!(o instanceof Student)) return false; Student s (Student) o; return Objects.equals(id, s.id); }注意这里我只用学号判定相等因为学号在业务上唯一。如果你把姓名和年龄也加进去那同一个学生修改过年龄之后contains就有可能判定不相等这在学生管理场景里很容易出逻辑漏洞。equals里放哪些字段应该由业务唯一性决定而不是把所有字段都写上。4.3 泛型偷懒的代价类型擦除与ClassCastException很多教材会提一句ArrayList如果不写泛型默认就是ArrayListObject什么都能往里扔。有人图省事真的这么干ArrayList list new ArrayList(); list.add(new Student(1001, 张三, 18, 计算机1班)); list.add(这是一个字符串);等到遍历取数据时你记得里面全是Student于是强转Student s (Student) list.get(1);这句代码会直接抛ClassCastException因为第2个元素其实是个String强转当然失败。这种错误在编译期完全发现不了等到运行才炸而且炸的时候往往和实际入坑的代码隔得很远排查成本很高。写上行规的泛型之后编译器会在你做add时检查类型取出来也不用强转ArrayListStudent list new ArrayList(); list.add(new Student(...)); // 类型不对根本编译不过 Student s list.get(0); // 不用强转这里有一个值得展开的背景知识Java的泛型是类型擦除的泛型信息只存在于编译期运行时ArrayList并不知道自己存的是什么类型。你写成ArrayListStudent编译后字节码里还是ArrayListObject但编译器已经在入口处插入了类型检查在读取处插入了隐式强转。IDE报红、编译报错都是这个编译期防火墙在起作用。在写学生管理系统时我强烈建议从一开始就写满泛型不要偷这个懒。你可能觉得反正我存的全是Student但人总有失误的时候让编译器帮你把关成本最低。另外如果你用的是Java 7及以上new ArrayList()后面的尖括号可以不写类型通过类型推断自动补齐代码更干净。5. 把整个系统串起来主菜单循环与后续扩展方向5.1 一个清晰可控的主流程长什么样前面的Student类和管理方法都准备好了最后一步是把它们拼成一个能跑起来的系统。学生管理系统一般用控制台交互核心是一个主菜单循环显示菜单、接收用户输入、根据选择执行操作、回到菜单。这里直接给一个骨架public static void main(String[] args) { StudentManager manager new StudentManager(); Scanner sc new Scanner(System.in); while (true) { System.out.println( 学生管理系统 ); System.out.println(1. 添加学生); System.out.println(2. 删除学生); System.out.println(3. 修改学生信息); System.out.println(4. 查看所有学生); System.out.println(5. 退出系统); System.out.print(请选择操作); int choice sc.nextInt(); sc.nextLine(); // 吸收掉换行符 switch (choice) { case 1: System.out.print(请输入学号); String id sc.nextLine(); System.out.print(请输入姓名); String name sc.nextLine(); // 为了演示年龄在这里直接给0正式代码应sc.nextInt() Student s new Student(id, name, 0, 待定班级); manager.addStudent(s); break; case 2: System.out.print(请输入要删除的学号); String delId sc.nextLine(); manager.removeById(delId); break; // case 3, case 4 同理 case 5: System.out.println(系统已退出); return; default: System.out.println(无效选项请重新输入); } } }这个骨架里有几个值得注意的细节。第一个是sc.nextInt()后面的sc.nextLine()nextInt只读取了数字会把数字后面的换行符留在输入缓冲区里如果之后再用nextLine读取字符串就会直接读到那个空行导致输入一个学号结果没反应。这个坑极其常见处理方式就是吃一个多余的换行。第二个是无限循环加return退出。这种写法在控制台交互里没问题因为程序的生命周期就是靠这个循环维持的。写成System.exit(0)也可以但return更加直观代码阅读者一看就知道是结束整个main方法。第三个是默认分支。如果用户输入了超出1~5的选项一定要有default兜底提示重新输入否则switch会什么也不做就回到菜单。看起来是小细节但对用户体验影响很大。我给这段代码里的年龄用0做演示值是因为要先把主流程跑通再加细节。先让系统动起来再逐步完善输入校验、异常处理和字段必填检查是写控制台项目非常实用的一个策略。很多初学者一上来就想把所有输入都做完美校验结果卡在细节里迟迟看不到程序的完整效果反而容易丧失信心。5.2 当数据量变大之后ArrayList还够用吗学生管理系统做完有好奇心的同学可能会问现在学生几十个、几百个ArrayList完全没问题。但如果数据量变成几万、几十万呢是不是还够用要分情况看。如果操作主要是按后缀追加学生和按索引查看ArrayList依然高效因为尾部添加和按下标访问都是O(1)。但有两个场景ArrayList会变得吃力第一个是频繁在中间位置插入或删除。比如按照学号有序插入这种需求每次插入都要让后续元素整体后移平均时间复杂度O(n)。数据少无感数据多了性能下降非常明显。这种场景更适合LinkedList它虽然随机访问慢但在已知节点的前提下插入删除是O(1)。第二个是频繁按某个非索引字段查找。ArrayList的查找只能线性遍历O(n)从头扫到尾。学生管理系统里按学号查找、按姓名模糊查询数据规模大了之后每条查询都要扫全表。这时就会自然引出哈希表的思想——按学号直接算出存储位置查询变成O(1)。这也就是后面学习HashMap的动机。从这个角度看学生管理系统虽然是个入门项目但它的价值不只是练习语法而是让你亲手体会不同数据结构适合不同场景。ArrayList解决了动态数组的问题但它不是银弹。当你真正理解了课程里那句数据结构的选择决定算法效率再回头看这个系统就知道下一步该学什么了。我在实际写这类教学项目时还有一种体会纸上谈兵远远不够代码写出来跑一遍再在调试器里观察变量和底层数组的变化这部分才算真正过脑了。建议你用IDE的调试模式在grow方法附近打断点观察ArrayList底层数组长度一次次从10变成15、15变成22或者在删除元素时亲眼看后续元素往前挪的过程。今天这篇讲的扩容机制、索引错位、equals判定全都可以在调试器里得到验证跑通一遍之后你对ArrayList的理解会扎实很多。
