写 Java 写久了会发现程序里最不容易出问题的地方往往不是复杂框架而是那些天天在用的基础语法。Java流程控制这一块尤其容易被人低估你以为 if/else、for/while 谁都会写可真到面试或者线上排查故障时翻车的十有八九都出现在这些最不起眼的环节。这篇就把条件分支、循环结构和跳转关键字从头到尾捋一遍适合刚学 Java 的新人也适合准备 Java 面试、想系统过一遍基础的人。把这些内容吃透你写出来的代码会明显干净排查逻辑问题的思路也会清晰很多。这里不打算堆一堆概念直接进入实操视角把我自己在项目里和带人过程中积累的经验、踩过的坑一起说出来。1. 先看清 Java 流程控制的真实位置1.1 代码执行的三条路线顺序、分支、循环不夸张地说任何一个 Java 程序不管外面包了多少层框架落实到方法内部执行路线都只有三条顺序执行、条件分支和循环。默认情况下代码从上往下逐行执行这叫顺序结构。但业务逻辑不可能永远是一条直线比如要根据用户角色决定显示哪些菜单要根据库存数量判断能否下单这就是条件分支。再比如要批量导入几千条数据要在数组中找最大值这就是循环。理解了这个视角之后你会发现 Java 流程控制其实是整个代码世界的“道路规划系统”。if/else、switch 决定往哪走for/while 决定走几遍break/continue/return 决定什么时候停下来。这个系统设计得越合理代码越容易读懂设计得乱代码就成了意大利面条后期维护成本高到让人头大。1.2 为什么这块内容在面试里频繁出现很多准备 Java 面试的人喜欢背高并发、JVM、Spring 源码但拿到基础题仍然容易愣住。原因很简单流程控制是最底层的逻辑表达工具框架可以封装业务但封装不掉判断和循环。实际面试中问你“Java 的 for 循环和迭代器有什么区别”“增强 for 循环中删除元素会怎样”问的不是语法本身而是你有没有真正理解底层是怎么跑的。这些点网上一般叫 Java 八股文但我更愿意把它看成一面照妖镜。基础越牢固的人遇到这类问题越能讲出底层原理和业务场景而不是死记结论。1.3 判断自己是否掌握流程控制的标准我觉得可以用三个标准衡量第一看到一段包含多层 if 和嵌套循环的代码能快速在脑子里画出执行路径哪条分支会走到、哪个循环会退出第二写的循环程序没有隐性死循环、没有差一错误、没有莫名其妙的并发修改异常第三能把复杂的判断条件抽成方法把深层嵌套用卫语句化解让读代码的人不用来回滚动鼠标。如果这三条还有欠缺那这篇值得认真看完。2. 条件分支if/else 这样写才不容易踩坑2.1 基本语法和几个容易忽略的细节if/else 是 Java 里最常用的条件分支基本语法很简单int score 85; if (score 90) { System.out.println(A); } else if (score 80) { System.out.println(B); } else { System.out.println(C); }这里有几个细节新人很容易忽略。第一Java 的条件表达式必须是boolean类型不能直接写if (1)这种在 C 语言里常见的写法。很多转行过来的同学刚开始会写错编译器直接报错反而是好事能逼着你养成类型清晰的习惯。第二else if并不是一个独立关键字本质上是else { if (...) }的简写。所以它和前面的 if 其实是一个嵌套结构。理解这一点写多层条件时才不会把逻辑搞混。第三if、else 后面如果没有大括号只能跟一条语句。我强烈建议不管有几条代码都加大括号否则后续加需求的时候极其容易翻车。举个例子if (user ! null) System.out.println(user.getName()); // 新增一行给用户发通知 sendNotify(user); // 这行其实已经不在 if 控制范围内了sendNotify(user)会被无条件执行这种 bug 在 Code Review 中真的非常常见。2.2 短路运算符与流程控制的联动和||本身的运算结果虽然是 boolean但它们对流程控制的影响远比你想象的大。Java 的和||是短路运算左边表达式已经能决定整个结果时右边不会执行。int a 1; int b 5; if (a 0 b 10) { System.out.println(b); // 这里 b 是 6 } if (a 5 b 10) { System.out.println(不会进入); } System.out.println(b); // b 仍然是 6第二个 if 的 b 没有执行这块内容经常被拿来和自增、赋值结合出面试题。与其去背各种乱七八糟的结果不如记住一条短路右边到底执行不执行取决于左边的结果是否已经能决定整体。写业务代码时短路特性最大的价值是先判空再访问属性if (list ! null list.size() 0) { // 安全访问 }但反向使用容易踩坑。比如想把两个条件都执行一遍却用了第二个条件里的操作在第一个条件不满足时就不会发生。所以每次看到这种表达式我都会习惯性确认右边的副作用是不是真的必须执行2.3 用卫语句和条件拆分减少嵌套嵌套太深是 Java 代码可读性最大的杀手之一。比如下面这种层层嵌套public void process(Order order) { if (order ! null) { if (order.isPaid()) { if (order.getStock() 0) { doShip(order); } else { logStockError(order); } } else { logPayError(order); } } else { logNullError(); } }这种代码看着就累分支路径多了以后括号配对都能让人崩溃。实际开发中我更喜欢用卫语句提前返回把异常情况和非法状态先清理掉public void process(Order order) { if (order null) { logNullError(); return; } if (!order.isPaid()) { logPayError(order); return; } if (order.getStock() 0) { logStockError(order); return; } doShip(order); }这样主流程全部拍平每个方法在做“先排除异常再处理正事”的事情。代码行数差不多但读起来舒服得多。面试和实际代码 Review 中“减少嵌套”“使用卫语句”都是比较加分的设计意识。2.4 判断值相等不要用 处处适用条件分支里写等值判断时基本数据类型用没问题但对象比较必须要考虑equals。比如字符串String status getStatus(); if (success.equals(status)) { // 推荐这种写法常量放前面避免空指针 }把常量放前面是我多年养成的习惯。如果写成status.equals(success)一旦 status 是 null直接抛空指针把常量放前面即使 status 为 null也不会出问题只是条件不成立而已。这个习惯在大量 if 条件里能帮你省掉很多线上事故。3. switch 的写法和选型从传统 case 到新式表达式3.1 经典 switch 的 break 穿透问题当需要根据一个变量的多个离散取值做分流时switch 通常比一长串 if/else 更清晰。经典写法是int day 3; switch (day) { case 1: System.out.println(周一); break; case 2: System.out.println(周二); break; case 3: System.out.println(周三); break; default: System.out.println(其他); }这边最经典的坑是漏写break。如果 case 3 的代码后面没有 break程序执行完 “周三” 之后不会跳出 switch而会继续进入下面的 case直到遇到 break 或整个 switch 结束这就叫 case 穿透。不过在某些场景下case 穿透反而是有用技巧。比如判断月份有多少天int days; switch (month) { case 1: case 3: case 5: case 7: case 8: case 10: case 12: days 31; break; case 4: case 6: case 9: case 11: days 30; break; case 2: days 28; break; default: days 0; }这里共享同一个执行体就非常自然。如果不主动使用穿透那每个 case 后面都写 break 是基本要求这也是 Code Review 时我会重点看的位置。3.2 JDK 14 之后的 switch 表达式更值得用如果你还在用老式 switch我强烈建议了解一下现代写法。JDK 14 开始switch 支持了箭头语法和表达式返回值代码明显更安全int month 5; int days switch (month) { case 1, 3, 5, 7, 8, 10, 12 - 31; case 4, 6, 9, 11 - 30; case 2 - { // 如果需要多行逻辑用 yield 返回 boolean leap isLeapYear(2024); yield leap ? 29 : 28; } default - 0; };这种写法有几个明显优势第一多个值可以合并到一个 case不再需要连续堆 case第二箭头的语义天然就是“条件匹配后做这件事”不需要 break不存在穿透问题第三可以直接把 switch 结果赋值给变量在简单的值映射场景中非常简洁。如果项目 JDK 版本允许我个人的偏好是新代码一律使用箭头语法老代码保持原样、不主动大规模重构等维护到相关逻辑时顺手替换。3.3 switch 适合哪些场景不适合哪些场景我在实际选型时如果判断条件是范围比较比如分数区间、年龄区间优先用 if/else如果判断条件是有限个离散值比如状态码、枚举类型、菜单类型优先用 switch。用一张表概括就是对比项if/elseswitch判断条件类型任意 boolean 表达式整数、字符、枚举、字符串等离散值范围判断非常方便不方便嵌套复杂逻辑容易导致深层嵌套分支结构天然平铺空值处理条件里可以自由判断传入 null 会抛空指针可读性少量分支时清晰大量分支时累赘大量离散分支时更清晰还有一个常见面试考点是 switch 支持的数据类型。传统 switch 支持 int、char、short、byte 以及对应的包装类型也支持枚举和 String。String 类型从 Java 7 开始支持但注意switch (str)中如果 str 是 null运行时会抛出 NPE所以在 switch 之前先判空比较稳妥。4. for、while、do-while 与 foreach四种循环到底怎么选4.1 for 循环的执行顺序与自增时机for 循环是使用频率最高的一种循环它的执行顺序值得背下来。看这一段for (int i 0; i 3; i) { System.out.println(i); }执行顺序是先执行一次初始化语句int i 0然后判断i 3如果为 true进入循环体打印循环体结束之后执行更新语句i再回到判断重复这个过程。经常有人在这里记混尤其是更新语句什么时候执行。这里有个最直观的理解更新语句是在“本次循环体代码执行完成之后”执行而不是在进入循环体之前执行。类似“C 语言 for 循环顺序 1243”这种记忆法其实就是在表达初始化、判断、循环体、更新这么个先后关系。在循环体内部改控制变量是很多人容易犯的错误for (int i 0; i 10; i) { if (i 5) { i 9; // 人为跳转变量 } }这种代码在某些复杂算法里是有意为之但大多数情况下会破坏循环的可读性。如果你发现需要通过修改 i 来改变循环节奏更建议用 break、continue 来表达意图。4.2 while 循环处理次数不确定的业务for 循环适合循环次数明确的场景。如果不知道要循环多少次只知道什么时候该停下来就轮到 while 上场。最典型的就是读取文件内容直到读到文件结尾BufferedReader reader new BufferedReader(new FileReader(data.txt)); String line; while ((line reader.readLine()) ! null) { System.out.println(line); }每一次循环开始前都要判断条件。条件一旦在中间被改掉下一次循环开始才发现并退出。所以写 while 循环时必须保证循环体的某条路径一定会改变条件相关的变量否则就会死循环。工作中我常用的一个检查方法是把条件变量在循环体内出现的每一个位置都找出来看看有没有可能在某条路径上没有任何改动。如果存在这样的路径那基本就是死循环候选。4.3 do-while 至少执行一次的场景do-while 的语法特点是先执行循环体再判断条件所以无论条件是否成立循环体至少会执行一次。业务里很适合做“先展示一次菜单再根据输入决定是否继续”的流程Scanner scanner new Scanner(System.in); int choice; do { System.out.println(请选择操作1-查询2-新增0-退出); choice scanner.nextInt(); } while (choice ! 0);如果是 while 版本你需要先在循环前加一次重复代码才能达到同样效果。所以当你明确业务里“至少要做一次然后再判断要不要继续”时优先考虑 do-while。这里提一个很容易忽略的点do-while 后面是有分号的。我见过不少同事在while (choice ! 0)后面忘了写分号这是语法错误编译器会提醒但还是要养成习惯。4.4 增强 for 和 forEach 的区别在哪增强 for 循环是 Java 5 引入的遍历集合和数组非常方便ListString names Arrays.asList(Tom, Jack, Lucy); for (String name : names) { System.out.println(name); }语法简洁但它并不是什么黑魔法。编译器会把这种写法转换成基于迭代器的循环数组则转换成普通 for。也就是说增强 for 底层用的是 Iterator这也是为什么它和集合删除操作有那么多爱恨情仇。使用增强 for 时无法直接获取当前元素下标需要下标时我会回到传统 for。另外增强 for 遍历 List 时如果循环体里调用list.remove()之类修改结构的方法通常会在下一次迭代时抛ConcurrentModificationException这个后面单独展开。5. break、continue、return 和标签控制循环方向的四把钥匙5.1 break 只能跳出一层循环break 的作用是终止当前这一层的循环。比如for (int i 0; i 5; i) { if (i 3) { break; } System.out.println(i); }这段代码只输出 0、1、2i 等于 3 时循环直接结束也不会执行后面的 i4。break 只会跳出它所在的那一层循环外层循环不受影响。很多初学者在嵌套循环里只写一个 break以为整个两层循环都停了然后发现外层还在继续走。这是非常典型的理解偏差。5.2 continue 是跳过本次迭代continue 和 break 不同它不会结束整个循环只是跳过当前这一次循环体的剩余代码直接进入下一次迭代。for (int i 0; i 5; i) { if (i % 2 0) { continue; } System.out.println(i); // 只输出奇数 1、3 }使用 continue 时要小心它和更新语句的关系。在 for 循环里continue 之后会自动执行更新语句但在 while 循环里如果 continue 写在“变量更新语句”之前更新逻辑会被跳过进而可能导致死循环。比如int i 0; while (i 5) { if (i 2) { continue; // 这里 continue 跳过了后面的 i } i; }当 i 等于 2 时continue 直接回到条件判断i 永远没有机会变成 3于是死循环。这种问题特别隐蔽用 while 写复杂流程时需要提高警惕。5.3 return 跳出的是整个方法return 和 break 一个很重要的区别是return 跳出的是整个方法而不是当前的循环层。也就是说循环中执行到 return方法直接结束后面无论还有多少层循环都不会继续。public int findIndex(int[] arr, int target) { for (int i 0; i arr.length; i) { if (arr[i] target) { return i; } } return -1; }把找到结果后的出口从 break 换成 return代码能少写不少标记变量。这也是我把嵌套查找逻辑拆成独立方法的原因之一方法级 return 天然能跳出多层逻辑不需要额外状态。5.4 带标签的 break 和 continue 才是跳出多层循环的王牌如果确实需要从内层循环直接跳出外层循环Java 也提供了方案带标签的 break。标签的写法是在循环前写一个标识符加冒号比如int[][] matrix { {1, 2, 3}, {4, 5, 6}, {7, 8, 9} }; int target 8; boolean found false; outer: for (int i 0; i matrix.length; i) { for (int j 0; j matrix[i].length; j) { if (matrix[i][j] target) { found true; break outer; // 直接跳出外层循环 } } }这种语法本质上提供了一种受控制的跳转能力比 goto 温和得多因为它只能跳转到标记的循环层。不过我在代码 Review 里遇到标签跳转还是会比较谨慎如果一段逻辑需要靠标签才能写清楚通常意味着更好的方式是抽取独立方法然后直接 return。6. 实战重构用流程控制知识救活嵌套逻辑6.1 从三层 if 嵌套到卫语句日常开发中最常见的问题是业务需求不断叠加条件判断不断嵌套。就拿前文的订单示例来说视觉上第一版看着还行可一旦每个分支里还要再处理日志、短信、库存操作整个方法瞬间爆炸。我的重构思路通常是非法情况提前返回主流程放到最后。这样做不仅能减少嵌套层数还能让测试更容易覆盖先测各种异常输入再测正常路径。如果把多个条件放在一个 if 里但我又不希望每个失败分支都有独立处理可以合并成“收集所有异常原因再统一处理”ListString errors new ArrayList(); if (order null) { errors.add(订单为空); } if (order ! null !order.isPaid()) { errors.add(订单未支付); } if (order ! null order.getStock() 0) { errors.add(库存不足); } if (!errors.isEmpty()) { throw new IllegalArgumentException(String.join(,, errors)); } doShip(order);这种写法在表单校验里特别实用一条条条件独立判断逻辑清晰后续加校验也方便。6.2 把循环逻辑提炼成方法循环本身并不可怕可怕的是循环体里带了大量复杂业务逻辑。我见过一个历史方法里有个 40 行的 for 循环里面同时在做格式化、库存扣减、日志拼接、性能统计几乎没办法测试。后来重构的时候我把循环体里每件相对独立的事都拆成方法for (Order order : orders) { if (!canShip(order)) { continue; } int stock calculateStockAfterShip(order); logShipment(order, stock); }这样的好处是每个方法都可以单独测试循环只是负责“把这些操作应用于每个元素”。实际编码时拿到一段循环先问自己如果抽出循环体命名为一个方法这个名字应该叫什么如果答不上来说明这段逻辑还不够内聚。6.3 Stream 能替代一部分循环但不能滥用Java 8 的 Stream 让集合操作变得更声明式。比如从用户列表里筛选成年人并取出姓名ListString names users.stream() .filter(user - user.getAge() 18) .map(User::getName) .collect(Collectors.toList());这段逻辑用传统 for 也能写但 Stream 的链式风格更强调做什么而不是怎么循环。不过在性能敏感的大循环、复杂状态累积场景里传统 for 的可读性和性能往往更可控。我做技术选型时有一个很主观但实用的原则如果 Stream 能让代码短一半并且语义更清晰就使用如果为了转 Stream 要引入大量技巧就老实写 for。6.4 从冒泡排序看双重循环边界很多 Java 基础练习题绕不开冒泡排序它也是最容易把循环边界写错的场景之一int[] arr {5, 2, 9, 1, 5, 6}; for (int i 0; i arr.length - 1; i) { for (int j 0; j arr.length - 1 - i; j) { if (arr[j] arr[j 1]) { int temp arr[j]; arr[j] arr[j 1]; arr[j 1] temp; } } }外层循环控制“需要多少轮比较”内层循环控制“这一轮比较到哪个位置”。因为每一轮都会把当前最大值放到末尾所以下一轮就不用再比已经排好的尾部元素内层边界要减去 i。这个细节就是典型的差一错误。每写一个双重循环我都会先在纸上画一两个小数组推演几轮再运行验证结果比凭感觉写可靠得多。7. 高频问题排查与面试坑点实录7.1 增强 for 遍历时删除集合元素为什么报错这个场景几乎每个 Java 开发者都会遇到ListString list new ArrayList(Arrays.asList(A, B, C)); for (String s : list) { if (B.equals(s)) { list.remove(s); } }运行后大概率抛ConcurrentModificationException。原因在于增强 for 底层使用 Iterator 遍历每次next()时都会检查集合的modCount是否发生变化。循环体内直接调用list.remove()会修改modCount迭代器发现数据被外部改过立刻抛异常。如果想边遍历边删除正确姿势有几种// 方式一使用 Iterator 自己的 remove IteratorString iterator list.iterator(); while (iterator.hasNext()) { String s iterator.next(); if (B.equals(s)) { iterator.remove(); } } // 方式二使用 Java 8 的 removeIf list.removeIf(s - B.equals(s));优先推荐removeIf一行搞定语义最清晰。7.2 死循环怎么定位和避免死循环大概是最让人崩溃的线上问题之一。最常见的原因是条件变量忘记更新比如int i 0; while (i 100) { System.out.println(i); // 忘了 i }还有一种是条件边界写反比如把写成了循环一次都不执行还好说怕的是把写成且条件从 false 开始永远无法退出。生产环境遇到疑似死循环我第一反应是抓线程栈。可以先执行jstack pid或者用 Arthas 的thread -n查看最繁忙的几个线程基本能看到卡在业务代码的哪一行。只要定位到具体行结合循环条件很快就能找到变量没更新的地方。更关键的是预防。我会给自己定一条规矩凡是 while 循环循环体内必须能在有限步内改变某个与退出条件相关的变量。写完后至少阅读一遍所有可能路径确认每条路径要么退出循环、要么会改变条件、要么明确用 break 中断。7.3 自增与短路结合的条件判断这类题目经常在 Java 笔试和面试中出现int i 0; boolean flag (i 0) (i 3); System.out.println(i); // 输出多少因为第一个表达式i 0中 i 初始为 0先取 0 再自增所以结果是 false整个已经确定为 false第二个i不会执行。最终 i 的值是 1而不是 2。遇到这类题别着急算先画一条执行流左侧结果是什么能否确定整体结果右侧是否还会执行。把这个思考路径搞清楚不管怎么变换都不容易错。7.4 流程控制高频问题与排查速查表现象常见原因处理方式某个 if 分支始终进不去条件表达式类型不对、字符串用了 比较检查条件是否 boolean对象比较换 equals循环比预期多执行一次或少执行一次边界符号写错比如写成拿一个最小用例单步调试循环中间突然抛异常for 循环里直接删除/添加集合元素使用 Iterator.remove 或 removeIfswitch 结果跟预期不符case 后面漏写 break改用箭头语法 switch程序卡住不退出while 条件变量未更新检查死循环抓线程栈定位嵌套循环只用 break 没跳出外层break 只作用于本层循环使用带标签的 break 或抽方法 return循环体里修改了计数器导致结果错乱对循环变量赋值用 break/continue 表达流程减少手动改 i这段内容写到这里我特别想说一个自己的体会新手阶段最容易忽略流程控制的“控制”二字以为它就是一堆语法代码写多了以后才会发现真正的难点在于怎么把复杂的业务流程翻译成清晰、无死路、易维护的控制结构。遇到逻辑诡异的问题我一般先检查三件事有没有短路让某段代码没执行、有没有在循环体里改计数器或条件变量、break 和 continue 到底作用在哪一层。这三件事排查完一大半控制流相关的问题都能水落石出。
写 Java 写久了会发现程序里最不容易出问题的地方往往不是复杂框架而是那些天天在用的基础语法。Java流程控制这一块尤其容易被人低估你以为 if/else、for/while 谁都会写可真到面试或者线上排查故障时翻车的十有八九都出现在这些最不起眼的环节。这篇就把条件分支、循环结构和跳转关键字从头到尾捋一遍适合刚学 Java 的新人也适合准备 Java 面试、想系统过一遍基础的人。把这些内容吃透你写出来的代码会明显干净排查逻辑问题的思路也会清晰很多。这里不打算堆一堆概念直接进入实操视角把我自己在项目里和带人过程中积累的经验、踩过的坑一起说出来。1. 先看清 Java 流程控制的真实位置1.1 代码执行的三条路线顺序、分支、循环不夸张地说任何一个 Java 程序不管外面包了多少层框架落实到方法内部执行路线都只有三条顺序执行、条件分支和循环。默认情况下代码从上往下逐行执行这叫顺序结构。但业务逻辑不可能永远是一条直线比如要根据用户角色决定显示哪些菜单要根据库存数量判断能否下单这就是条件分支。再比如要批量导入几千条数据要在数组中找最大值这就是循环。理解了这个视角之后你会发现 Java 流程控制其实是整个代码世界的“道路规划系统”。if/else、switch 决定往哪走for/while 决定走几遍break/continue/return 决定什么时候停下来。这个系统设计得越合理代码越容易读懂设计得乱代码就成了意大利面条后期维护成本高到让人头大。1.2 为什么这块内容在面试里频繁出现很多准备 Java 面试的人喜欢背高并发、JVM、Spring 源码但拿到基础题仍然容易愣住。原因很简单流程控制是最底层的逻辑表达工具框架可以封装业务但封装不掉判断和循环。实际面试中问你“Java 的 for 循环和迭代器有什么区别”“增强 for 循环中删除元素会怎样”问的不是语法本身而是你有没有真正理解底层是怎么跑的。这些点网上一般叫 Java 八股文但我更愿意把它看成一面照妖镜。基础越牢固的人遇到这类问题越能讲出底层原理和业务场景而不是死记结论。1.3 判断自己是否掌握流程控制的标准我觉得可以用三个标准衡量第一看到一段包含多层 if 和嵌套循环的代码能快速在脑子里画出执行路径哪条分支会走到、哪个循环会退出第二写的循环程序没有隐性死循环、没有差一错误、没有莫名其妙的并发修改异常第三能把复杂的判断条件抽成方法把深层嵌套用卫语句化解让读代码的人不用来回滚动鼠标。如果这三条还有欠缺那这篇值得认真看完。2. 条件分支if/else 这样写才不容易踩坑2.1 基本语法和几个容易忽略的细节if/else 是 Java 里最常用的条件分支基本语法很简单int score 85; if (score 90) { System.out.println(A); } else if (score 80) { System.out.println(B); } else { System.out.println(C); }这里有几个细节新人很容易忽略。第一Java 的条件表达式必须是boolean类型不能直接写if (1)这种在 C 语言里常见的写法。很多转行过来的同学刚开始会写错编译器直接报错反而是好事能逼着你养成类型清晰的习惯。第二else if并不是一个独立关键字本质上是else { if (...) }的简写。所以它和前面的 if 其实是一个嵌套结构。理解这一点写多层条件时才不会把逻辑搞混。第三if、else 后面如果没有大括号只能跟一条语句。我强烈建议不管有几条代码都加大括号否则后续加需求的时候极其容易翻车。举个例子if (user ! null) System.out.println(user.getName()); // 新增一行给用户发通知 sendNotify(user); // 这行其实已经不在 if 控制范围内了sendNotify(user)会被无条件执行这种 bug 在 Code Review 中真的非常常见。2.2 短路运算符与流程控制的联动和||本身的运算结果虽然是 boolean但它们对流程控制的影响远比你想象的大。Java 的和||是短路运算左边表达式已经能决定整个结果时右边不会执行。int a 1; int b 5; if (a 0 b 10) { System.out.println(b); // 这里 b 是 6 } if (a 5 b 10) { System.out.println(不会进入); } System.out.println(b); // b 仍然是 6第二个 if 的 b 没有执行这块内容经常被拿来和自增、赋值结合出面试题。与其去背各种乱七八糟的结果不如记住一条短路右边到底执行不执行取决于左边的结果是否已经能决定整体。写业务代码时短路特性最大的价值是先判空再访问属性if (list ! null list.size() 0) { // 安全访问 }但反向使用容易踩坑。比如想把两个条件都执行一遍却用了第二个条件里的操作在第一个条件不满足时就不会发生。所以每次看到这种表达式我都会习惯性确认右边的副作用是不是真的必须执行2.3 用卫语句和条件拆分减少嵌套嵌套太深是 Java 代码可读性最大的杀手之一。比如下面这种层层嵌套public void process(Order order) { if (order ! null) { if (order.isPaid()) { if (order.getStock() 0) { doShip(order); } else { logStockError(order); } } else { logPayError(order); } } else { logNullError(); } }这种代码看着就累分支路径多了以后括号配对都能让人崩溃。实际开发中我更喜欢用卫语句提前返回把异常情况和非法状态先清理掉public void process(Order order) { if (order null) { logNullError(); return; } if (!order.isPaid()) { logPayError(order); return; } if (order.getStock() 0) { logStockError(order); return; } doShip(order); }这样主流程全部拍平每个方法在做“先排除异常再处理正事”的事情。代码行数差不多但读起来舒服得多。面试和实际代码 Review 中“减少嵌套”“使用卫语句”都是比较加分的设计意识。2.4 判断值相等不要用 处处适用条件分支里写等值判断时基本数据类型用没问题但对象比较必须要考虑equals。比如字符串String status getStatus(); if (success.equals(status)) { // 推荐这种写法常量放前面避免空指针 }把常量放前面是我多年养成的习惯。如果写成status.equals(success)一旦 status 是 null直接抛空指针把常量放前面即使 status 为 null也不会出问题只是条件不成立而已。这个习惯在大量 if 条件里能帮你省掉很多线上事故。3. switch 的写法和选型从传统 case 到新式表达式3.1 经典 switch 的 break 穿透问题当需要根据一个变量的多个离散取值做分流时switch 通常比一长串 if/else 更清晰。经典写法是int day 3; switch (day) { case 1: System.out.println(周一); break; case 2: System.out.println(周二); break; case 3: System.out.println(周三); break; default: System.out.println(其他); }这边最经典的坑是漏写break。如果 case 3 的代码后面没有 break程序执行完 “周三” 之后不会跳出 switch而会继续进入下面的 case直到遇到 break 或整个 switch 结束这就叫 case 穿透。不过在某些场景下case 穿透反而是有用技巧。比如判断月份有多少天int days; switch (month) { case 1: case 3: case 5: case 7: case 8: case 10: case 12: days 31; break; case 4: case 6: case 9: case 11: days 30; break; case 2: days 28; break; default: days 0; }这里共享同一个执行体就非常自然。如果不主动使用穿透那每个 case 后面都写 break 是基本要求这也是 Code Review 时我会重点看的位置。3.2 JDK 14 之后的 switch 表达式更值得用如果你还在用老式 switch我强烈建议了解一下现代写法。JDK 14 开始switch 支持了箭头语法和表达式返回值代码明显更安全int month 5; int days switch (month) { case 1, 3, 5, 7, 8, 10, 12 - 31; case 4, 6, 9, 11 - 30; case 2 - { // 如果需要多行逻辑用 yield 返回 boolean leap isLeapYear(2024); yield leap ? 29 : 28; } default - 0; };这种写法有几个明显优势第一多个值可以合并到一个 case不再需要连续堆 case第二箭头的语义天然就是“条件匹配后做这件事”不需要 break不存在穿透问题第三可以直接把 switch 结果赋值给变量在简单的值映射场景中非常简洁。如果项目 JDK 版本允许我个人的偏好是新代码一律使用箭头语法老代码保持原样、不主动大规模重构等维护到相关逻辑时顺手替换。3.3 switch 适合哪些场景不适合哪些场景我在实际选型时如果判断条件是范围比较比如分数区间、年龄区间优先用 if/else如果判断条件是有限个离散值比如状态码、枚举类型、菜单类型优先用 switch。用一张表概括就是对比项if/elseswitch判断条件类型任意 boolean 表达式整数、字符、枚举、字符串等离散值范围判断非常方便不方便嵌套复杂逻辑容易导致深层嵌套分支结构天然平铺空值处理条件里可以自由判断传入 null 会抛空指针可读性少量分支时清晰大量分支时累赘大量离散分支时更清晰还有一个常见面试考点是 switch 支持的数据类型。传统 switch 支持 int、char、short、byte 以及对应的包装类型也支持枚举和 String。String 类型从 Java 7 开始支持但注意switch (str)中如果 str 是 null运行时会抛出 NPE所以在 switch 之前先判空比较稳妥。4. for、while、do-while 与 foreach四种循环到底怎么选4.1 for 循环的执行顺序与自增时机for 循环是使用频率最高的一种循环它的执行顺序值得背下来。看这一段for (int i 0; i 3; i) { System.out.println(i); }执行顺序是先执行一次初始化语句int i 0然后判断i 3如果为 true进入循环体打印循环体结束之后执行更新语句i再回到判断重复这个过程。经常有人在这里记混尤其是更新语句什么时候执行。这里有个最直观的理解更新语句是在“本次循环体代码执行完成之后”执行而不是在进入循环体之前执行。类似“C 语言 for 循环顺序 1243”这种记忆法其实就是在表达初始化、判断、循环体、更新这么个先后关系。在循环体内部改控制变量是很多人容易犯的错误for (int i 0; i 10; i) { if (i 5) { i 9; // 人为跳转变量 } }这种代码在某些复杂算法里是有意为之但大多数情况下会破坏循环的可读性。如果你发现需要通过修改 i 来改变循环节奏更建议用 break、continue 来表达意图。4.2 while 循环处理次数不确定的业务for 循环适合循环次数明确的场景。如果不知道要循环多少次只知道什么时候该停下来就轮到 while 上场。最典型的就是读取文件内容直到读到文件结尾BufferedReader reader new BufferedReader(new FileReader(data.txt)); String line; while ((line reader.readLine()) ! null) { System.out.println(line); }每一次循环开始前都要判断条件。条件一旦在中间被改掉下一次循环开始才发现并退出。所以写 while 循环时必须保证循环体的某条路径一定会改变条件相关的变量否则就会死循环。工作中我常用的一个检查方法是把条件变量在循环体内出现的每一个位置都找出来看看有没有可能在某条路径上没有任何改动。如果存在这样的路径那基本就是死循环候选。4.3 do-while 至少执行一次的场景do-while 的语法特点是先执行循环体再判断条件所以无论条件是否成立循环体至少会执行一次。业务里很适合做“先展示一次菜单再根据输入决定是否继续”的流程Scanner scanner new Scanner(System.in); int choice; do { System.out.println(请选择操作1-查询2-新增0-退出); choice scanner.nextInt(); } while (choice ! 0);如果是 while 版本你需要先在循环前加一次重复代码才能达到同样效果。所以当你明确业务里“至少要做一次然后再判断要不要继续”时优先考虑 do-while。这里提一个很容易忽略的点do-while 后面是有分号的。我见过不少同事在while (choice ! 0)后面忘了写分号这是语法错误编译器会提醒但还是要养成习惯。4.4 增强 for 和 forEach 的区别在哪增强 for 循环是 Java 5 引入的遍历集合和数组非常方便ListString names Arrays.asList(Tom, Jack, Lucy); for (String name : names) { System.out.println(name); }语法简洁但它并不是什么黑魔法。编译器会把这种写法转换成基于迭代器的循环数组则转换成普通 for。也就是说增强 for 底层用的是 Iterator这也是为什么它和集合删除操作有那么多爱恨情仇。使用增强 for 时无法直接获取当前元素下标需要下标时我会回到传统 for。另外增强 for 遍历 List 时如果循环体里调用list.remove()之类修改结构的方法通常会在下一次迭代时抛ConcurrentModificationException这个后面单独展开。5. break、continue、return 和标签控制循环方向的四把钥匙5.1 break 只能跳出一层循环break 的作用是终止当前这一层的循环。比如for (int i 0; i 5; i) { if (i 3) { break; } System.out.println(i); }这段代码只输出 0、1、2i 等于 3 时循环直接结束也不会执行后面的 i4。break 只会跳出它所在的那一层循环外层循环不受影响。很多初学者在嵌套循环里只写一个 break以为整个两层循环都停了然后发现外层还在继续走。这是非常典型的理解偏差。5.2 continue 是跳过本次迭代continue 和 break 不同它不会结束整个循环只是跳过当前这一次循环体的剩余代码直接进入下一次迭代。for (int i 0; i 5; i) { if (i % 2 0) { continue; } System.out.println(i); // 只输出奇数 1、3 }使用 continue 时要小心它和更新语句的关系。在 for 循环里continue 之后会自动执行更新语句但在 while 循环里如果 continue 写在“变量更新语句”之前更新逻辑会被跳过进而可能导致死循环。比如int i 0; while (i 5) { if (i 2) { continue; // 这里 continue 跳过了后面的 i } i; }当 i 等于 2 时continue 直接回到条件判断i 永远没有机会变成 3于是死循环。这种问题特别隐蔽用 while 写复杂流程时需要提高警惕。5.3 return 跳出的是整个方法return 和 break 一个很重要的区别是return 跳出的是整个方法而不是当前的循环层。也就是说循环中执行到 return方法直接结束后面无论还有多少层循环都不会继续。public int findIndex(int[] arr, int target) { for (int i 0; i arr.length; i) { if (arr[i] target) { return i; } } return -1; }把找到结果后的出口从 break 换成 return代码能少写不少标记变量。这也是我把嵌套查找逻辑拆成独立方法的原因之一方法级 return 天然能跳出多层逻辑不需要额外状态。5.4 带标签的 break 和 continue 才是跳出多层循环的王牌如果确实需要从内层循环直接跳出外层循环Java 也提供了方案带标签的 break。标签的写法是在循环前写一个标识符加冒号比如int[][] matrix { {1, 2, 3}, {4, 5, 6}, {7, 8, 9} }; int target 8; boolean found false; outer: for (int i 0; i matrix.length; i) { for (int j 0; j matrix[i].length; j) { if (matrix[i][j] target) { found true; break outer; // 直接跳出外层循环 } } }这种语法本质上提供了一种受控制的跳转能力比 goto 温和得多因为它只能跳转到标记的循环层。不过我在代码 Review 里遇到标签跳转还是会比较谨慎如果一段逻辑需要靠标签才能写清楚通常意味着更好的方式是抽取独立方法然后直接 return。6. 实战重构用流程控制知识救活嵌套逻辑6.1 从三层 if 嵌套到卫语句日常开发中最常见的问题是业务需求不断叠加条件判断不断嵌套。就拿前文的订单示例来说视觉上第一版看着还行可一旦每个分支里还要再处理日志、短信、库存操作整个方法瞬间爆炸。我的重构思路通常是非法情况提前返回主流程放到最后。这样做不仅能减少嵌套层数还能让测试更容易覆盖先测各种异常输入再测正常路径。如果把多个条件放在一个 if 里但我又不希望每个失败分支都有独立处理可以合并成“收集所有异常原因再统一处理”ListString errors new ArrayList(); if (order null) { errors.add(订单为空); } if (order ! null !order.isPaid()) { errors.add(订单未支付); } if (order ! null order.getStock() 0) { errors.add(库存不足); } if (!errors.isEmpty()) { throw new IllegalArgumentException(String.join(,, errors)); } doShip(order);这种写法在表单校验里特别实用一条条条件独立判断逻辑清晰后续加校验也方便。6.2 把循环逻辑提炼成方法循环本身并不可怕可怕的是循环体里带了大量复杂业务逻辑。我见过一个历史方法里有个 40 行的 for 循环里面同时在做格式化、库存扣减、日志拼接、性能统计几乎没办法测试。后来重构的时候我把循环体里每件相对独立的事都拆成方法for (Order order : orders) { if (!canShip(order)) { continue; } int stock calculateStockAfterShip(order); logShipment(order, stock); }这样的好处是每个方法都可以单独测试循环只是负责“把这些操作应用于每个元素”。实际编码时拿到一段循环先问自己如果抽出循环体命名为一个方法这个名字应该叫什么如果答不上来说明这段逻辑还不够内聚。6.3 Stream 能替代一部分循环但不能滥用Java 8 的 Stream 让集合操作变得更声明式。比如从用户列表里筛选成年人并取出姓名ListString names users.stream() .filter(user - user.getAge() 18) .map(User::getName) .collect(Collectors.toList());这段逻辑用传统 for 也能写但 Stream 的链式风格更强调做什么而不是怎么循环。不过在性能敏感的大循环、复杂状态累积场景里传统 for 的可读性和性能往往更可控。我做技术选型时有一个很主观但实用的原则如果 Stream 能让代码短一半并且语义更清晰就使用如果为了转 Stream 要引入大量技巧就老实写 for。6.4 从冒泡排序看双重循环边界很多 Java 基础练习题绕不开冒泡排序它也是最容易把循环边界写错的场景之一int[] arr {5, 2, 9, 1, 5, 6}; for (int i 0; i arr.length - 1; i) { for (int j 0; j arr.length - 1 - i; j) { if (arr[j] arr[j 1]) { int temp arr[j]; arr[j] arr[j 1]; arr[j 1] temp; } } }外层循环控制“需要多少轮比较”内层循环控制“这一轮比较到哪个位置”。因为每一轮都会把当前最大值放到末尾所以下一轮就不用再比已经排好的尾部元素内层边界要减去 i。这个细节就是典型的差一错误。每写一个双重循环我都会先在纸上画一两个小数组推演几轮再运行验证结果比凭感觉写可靠得多。7. 高频问题排查与面试坑点实录7.1 增强 for 遍历时删除集合元素为什么报错这个场景几乎每个 Java 开发者都会遇到ListString list new ArrayList(Arrays.asList(A, B, C)); for (String s : list) { if (B.equals(s)) { list.remove(s); } }运行后大概率抛ConcurrentModificationException。原因在于增强 for 底层使用 Iterator 遍历每次next()时都会检查集合的modCount是否发生变化。循环体内直接调用list.remove()会修改modCount迭代器发现数据被外部改过立刻抛异常。如果想边遍历边删除正确姿势有几种// 方式一使用 Iterator 自己的 remove IteratorString iterator list.iterator(); while (iterator.hasNext()) { String s iterator.next(); if (B.equals(s)) { iterator.remove(); } } // 方式二使用 Java 8 的 removeIf list.removeIf(s - B.equals(s));优先推荐removeIf一行搞定语义最清晰。7.2 死循环怎么定位和避免死循环大概是最让人崩溃的线上问题之一。最常见的原因是条件变量忘记更新比如int i 0; while (i 100) { System.out.println(i); // 忘了 i }还有一种是条件边界写反比如把写成了循环一次都不执行还好说怕的是把写成且条件从 false 开始永远无法退出。生产环境遇到疑似死循环我第一反应是抓线程栈。可以先执行jstack pid或者用 Arthas 的thread -n查看最繁忙的几个线程基本能看到卡在业务代码的哪一行。只要定位到具体行结合循环条件很快就能找到变量没更新的地方。更关键的是预防。我会给自己定一条规矩凡是 while 循环循环体内必须能在有限步内改变某个与退出条件相关的变量。写完后至少阅读一遍所有可能路径确认每条路径要么退出循环、要么会改变条件、要么明确用 break 中断。7.3 自增与短路结合的条件判断这类题目经常在 Java 笔试和面试中出现int i 0; boolean flag (i 0) (i 3); System.out.println(i); // 输出多少因为第一个表达式i 0中 i 初始为 0先取 0 再自增所以结果是 false整个已经确定为 false第二个i不会执行。最终 i 的值是 1而不是 2。遇到这类题别着急算先画一条执行流左侧结果是什么能否确定整体结果右侧是否还会执行。把这个思考路径搞清楚不管怎么变换都不容易错。7.4 流程控制高频问题与排查速查表现象常见原因处理方式某个 if 分支始终进不去条件表达式类型不对、字符串用了 比较检查条件是否 boolean对象比较换 equals循环比预期多执行一次或少执行一次边界符号写错比如写成拿一个最小用例单步调试循环中间突然抛异常for 循环里直接删除/添加集合元素使用 Iterator.remove 或 removeIfswitch 结果跟预期不符case 后面漏写 break改用箭头语法 switch程序卡住不退出while 条件变量未更新检查死循环抓线程栈定位嵌套循环只用 break 没跳出外层break 只作用于本层循环使用带标签的 break 或抽方法 return循环体里修改了计数器导致结果错乱对循环变量赋值用 break/continue 表达流程减少手动改 i这段内容写到这里我特别想说一个自己的体会新手阶段最容易忽略流程控制的“控制”二字以为它就是一堆语法代码写多了以后才会发现真正的难点在于怎么把复杂的业务流程翻译成清晰、无死路、易维护的控制结构。遇到逻辑诡异的问题我一般先检查三件事有没有短路让某段代码没执行、有没有在循环体里改计数器或条件变量、break 和 continue 到底作用在哪一层。这三件事排查完一大半控制流相关的问题都能水落石出。
