OJ题目列表里躺着“sdut-Java面向对象-10 常用类函数题”这种题目时很多人的第一反应是函数题补个方法而已总比写完整程序简单吧等你连着吃了几发“编译错误”和“答案错误”之后就会改变这个想法。这种题表面上是补代码实际上是在精准打击你对Java常用类的掌握程度。它考的是String的某个方法会不会用、StringBuilder和StringBuffer能不能在正确场景里选对、包装类的自动装箱拆箱有没有理解透甚至还包括Math和日期时间类这些平常不太注意的边角知识。今天我就拿这类题当切入口把Java面向对象课程里“常用类”这张考卷拆开揉碎。无论你是正在和sdut这类在线练习平台的测评页较劲的大二学生还是准备Java面试却被String、包装类问住的求职者这篇都值得耐心看完。我会把考点清单、读题门道、解题套路和避坑经验全盘倒出来最后还会用一个完整的函数题实例演示从读题到提交的整套流程。1. OJ函数题的本质与“常用类”考点的深层逻辑1.1 函数题到底在考什么补全方法不是从零写系统函数题是高校OJ、练习平台里很特殊的一类题型。它不会让你从main方法开始写完整程序而是直接给出一个类框架或者只给一个方法签名让你把某个方法的函数体补全。听起来很轻巧但它精确考核的是单一知识点评测端也只认方法逻辑对不对不关心你有没有多余代码。这类题型的核心其实就三件事。第一件读懂方法签名。方法名是什么、参数是什么类型、返回值是什么类型这三个点直接决定了你要写什么代码。第二件知道对应的知识点有哪些可用的工具方法。比如题目要求处理字符串你得想到String类有startsWith、substring、indexOf这些方法想到StringBuilder的append可以高效拼接。第三件处理各种边界情况。null、空串、负数、空字符、极长输入……这些才是函数题真正的“答案错误”重灾区。和完整的编程题相比函数题放弃了输入输出格式的考察也放弃了程序整体结构的考察把所有注意力集中在“这个知识点你会不会用”上。老师在批改时无法看到你的思考过程只通过隐藏测试用例来判断你的方法是否正确这就要求你不仅会写主流程还必须把各种异常输入都考虑周全。很多同学抱怨函数题比编程题还难正是因为编程题偶尔还能靠输出结果的运气混过去函数题却没有任何侥幸空间。1.2 为什么“常用类”注定是函数题的常客高校Java课程的推进顺序基本都遵循一条主线先讲基本语法和流程控制再讲类和对象、封装集成多态然后是抽象类和接口紧接着就是String、包装类、Math、日期时间这类“常用类”。这个位置恰好处于面向对象语法学完、还没进入集合框架的过渡带特别适合用短小精悍的函数题来检验阶段性学习成果。从出题人的角度看常用类就是一座“考点富矿”。String的方法数量多到可以单独出一轮填空题包装类有自动装箱拆箱和缓存池这种经典陷阱Math类有一堆静态方法适合做数值运算题日期时间类虽然出题率稍低但随便挑一个格式化规则就能让人头疼一批人。更关键的是这些知识点不需要庞大的程序上下文直接给出一个方法签名就能考和函数题的天然适配度极高。从学生的角度看常用类是整个Java学习链条上“承上启下”的关键环节。如果这个阶段没有把String的不可变性理解透没有把StringBuilder的拼接效率概念建立起来后面学集合框架时会频繁碰壁因为集合里最常见的操作就是toString输出、map的键比较、字符串与包装类之间的转换。我在辅导时见过太多学生卡在这种地方与其说是集合没学会不如说是常用类的底子松了。多说一句这些常用类知识和Java面试八股的重合度非常高。String为什么不可变、StringBuilder如何扩容、Integer的缓存范围是多少都是企业面试里的老熟人。所以别小看OJ里这些看似机械的函数填空题把它们做扎实了等于提前给面试做了一轮浅层预热。1.3 一道标准函数题的题面结构先看签名再看注释最后看样例一个标准函数题的题面通常由几部分组成题目描述、方法功能说明、给定的代码框架、可能存在的main测试代码以及输入输出样例。sdtu这类平台的题目编号不同但结构大同小异。这里我写一个通用的典型题面读完你就知道该怎么下手。// 题目给定的类框架 public class Main { public static void main(String[] args) { System.out.println(StringUtil.handle(sdut-java)); System.out.println(StringUtil.handle(hello)); } } class StringUtil { /** * 请实现该方法 * 当字符串以 sdut- 开头时返回去掉 sdut- 后的字符串 * 否则原样返回若 s 为 null 或空串返回空串 。 */ public static String handle(String s) { // 在这里补全代码 return null; // TODO } }在这种题里main方法往往是题目给的你只需要补全那个带注释的方法体。读题顺序我建议固定成三步第一步先看方法签名确定传入参数类型、方法名和返回类型这是方向第二步再看注释描述重点关注里面对边界情况的特殊要求比如“null返回什么”、“空格算不算空串”第三步才回头看main里的测试样例通过样例反推预期行为验证自己的理解是否和出题人一致。函数题唯一重要的事情只有一个方法面对各种输入时应该返回什么、做什么处理。题面描述再长无非是在为这个方法的行为做解释不要被那些大段的背景故事干扰。我见过不少学生花十分钟读题面最后却没看清注释里那行小字“s可能为null请自行判断”结果一提交就空指针异常。读题效率往往就决定了解题效率。2. 高频常用类知识点逐一拆解方法、原理和易错点2.1 String最熟悉也最容易踩坑的类String是Java里出场率最高的类没有之一但正因为太常见反而成了函数题里翻车最多的地方。核心原因在于它的不可变性。String底层保存字符的char数组被private final修饰在较新版本里可能是byte数组配合编码标记但终归不可变每个String对象创建后内容就固定了。任何看似“修改”字符串的操作比如replace、substring、toUpperCase真实行为都是创建一个新的String对象原对象纹丝不动。这个特性带来了很多连锁反应。第一字符串比较不能直接用因为比较的是对象引用地址而不是内容。两个内容完全相同的字符串完全可能是两个不同的对象必须用equals方法。第二字符串常量池让字面量字符串可以复用所以直接写出来的abc和abc往往指向同一个对象这也导致“看起来能用”的错觉。第三由于每次修改都产生新对象在循环里用拼接字符串会把性能拖垮这种场景下的解决方案不是优化语法而是换工具。函数题里String的高频考点集中在常用方法上我按使用频率整理了一份速查清单方法作用易错点length()返回字符串长度注意和数组的length属性区分charAt(int index)返回指定索引的字符索引越界会抛StringIndexOutOfBoundsExceptionsubstring(int begin[, int end])截取子串左闭右开end不包含indexOf(char/String)查找子串首次出现位置找不到返回-1startsWith(String) / endsWith(String)判断前缀/后缀参数为空串时恒为truecontains(CharSequence)判断是否包含子串底层也是indexOfreplace(char, char) / replaceAll(String, String)替换字符/正则替换replaceAll第一个参数是正则容易被特殊字符坑trim() / strip()去除首尾空白trim只能去除U0020的空白toCharArray()转字符数组适合频繁索引访问的场景split(String)按正则拆分注意点号和竖线需要转义equals / equalsIgnoreCase内容比较大坑别用比较内容compareTo(String)字典序比较返回值小于0/等于0/大于0isEmpty() / isBlank()判断空串isBlank还检查空白字符做函数题时遇到字符串操作先想清楚“这个功能对应哪个方法”再去翻文档确认参数细节。尤其是substring的右开区间我见过无数人栽在这上面。想取字符串s的前三个字符应该是s.substring(0, 3)返回的是第1到第3个字符第4个字符不包含这个“开区间”直觉需要特意训练。2.2 StringBuilder与StringBuffer可变字符串的效率担当String不可变带来一个直接后果频繁修改字符串时效率极差。假设你要把10000个字符拼接起来用String的操作每个字符都会创建一个新的String对象把旧内容复制一遍复杂度直接变成O(n²)数据量一大就能感受到明显卡顿。StringBuilder和StringBuffer就是为解决这个问题而生的它们的内部维护一个可变的字符数组append操作只是在数组末尾追加内容必要时才自动扩容。StringBuilder的常用方法其实不多append、insert、delete、reverse、toString、charAt、indexOf掌握这几个基本就能应付绝大多数函数题。有一个细节值得专门强调append方法的返回值是StringBuilder对象本身所以支持链式调用例如new StringBuilder().append(a).append(b).append(c)这一特性在很多题解里都能简化代码。另外reverse方法可以原地反转字符串序列遇到回文、反转类题目时很好用。StringBuffer和StringBuilder的功能几乎一模一样唯一区别是StringBuffer的方法都加了synchronized关键字线程安全但性能略低。在OJ函数题和绝大多数单线程场景下优先选择StringBuilder就好这也是面试时的高频考点。相关八股问题往往长这样“StringBuilder默认容量是多少”“扩容机制怎么实现的”答案是默认容量16当容量不足时新容量为旧容量乘以2再加2然后通过Arrays.copyOf把原数组内容复制进新数组。从源码层面理解StringBuilder有两个好处。一是遇到需要手动预设容量的大拼接场景时你可以通过构造方法直接指定初始容量避免多次扩容。二是能真正理解为什么循环里用拼接是坏习惯为什么用append在性能上能甩开几条街。函数题一般不直接考你写扩容代码但如果你能在题解里用到StringBuilder并保证不溢出、不超时就已经和其他同学拉开差距了。2.3 包装类自动装箱拆箱背后的隐藏陷阱Java是一门面向对象语言但基本类型int、double、char并不是对象。为了让这些基本类型也能以对象形式出现才有了对应的包装类Integer、Double、Character、Boolean等等。函数题里经常需要在这两者之间来回倒腾比如把字符串“123”转成数字123或者把字符数组里的数字字符转成对应数值这就涉及包装类的核心操作。自动装箱和拆箱是编译器提供的语法糖。当你写下Integer a 100时编译器实际执行的是Integer.valueOf(100)当你写下int b a时编译器实际执行的是a.intValue()。这种机制平时很贴心但也埋了一颗雷valueOf方法会使用缓存。Integer的valueOf在入参范围-128到127之间时直接返回常量池里缓存的同一个对象超出这个范围就new一个全新对象。这就导致了经典翻车现场Integer a 100; Integer b 100; System.out.println(a b); // true命中缓存 Integer c 200; Integer d 200; System.out.println(c d); // false超出缓存区间是两个不同对象这种差异在函数题里极其隐蔽。题目让你判断两个“整数”是否相等你想着用比较简单结果测试数据一过127就翻车。正确姿势只有一个包装类之间的比较一律用equals或者先拆箱成基本类型再用比较。如果你需要在函数题里做数值运算请非常小心地处理字符串和包装类型的互相转换Integer.parseInt是把字符串解析成基本类型intInteger.valueOf是返回包装对象这两个方法名字相近返回类型不同用错了直接编译报错。包装类的另一个考点是各种静态工具方法。Integer.toBinaryString、Integer.toHexString、Double.parseDouble、Character.isDigit、Character.isLetter这些方法在OJ题目里经常作为跳板出现。拿到一个包装类题目先想想它考的是“缓存陷阱”“自动装箱实现原理”还是“静态方法使用”对症下药会快很多。2.4 Math、日期时间类与System类容易被忽略的组合考点除了String和包装类常用类这个章节还会捎带考Math类、日期时间类和System类。Math类是个纯工具类构造方法是私有的所有方法都是静态的直接通过类名调用就行。函数题最常见的用法包括Math.PI计算圆面积、Math.max和min找最大值、Math.abs求绝对值、Math.pow算幂、Math.sqrt开根号、Math.random生成[0.0, 1.0)随机数。这些方法本身没有太多坑但要注意Math.round是返回long类型取整规则是“四舍五入但负数特殊”别和Math.floor混用。日期时间类在函数题里出镜率中等但一旦出现就是难点。老API有Date和Calendar新API有LocalDate、LocalDateTime和DateTimeFormatter新老API之间切换很容易让人懵。做这类题时先确定题目期望的是哪种API再看具体操作方法。比如要获取年份Calendar得用calendar.get(Calendar.YEAR)LocalDate直接localDate.getYear()写法完全不同。如果题目允许使用新API优先用LocalDate系列代码更简洁直观可读性也更好。System类在函数题里偶尔作为“工具人”出现。System.currentTimeMillis()返回当前时间戳毫秒数经常用来测量方法执行耗时System.arraycopy是数组复制的高效底层方法它在源码层面被ArrayList.copyOf大量调用。有些题目会让你实现数组复制逻辑你完全可以用System.arraycopy代替手写for循环既简洁又不会被挑出性能毛病。这些类有一个共同点方法多而杂但每个方法都很固定。备考策略不是死记硬背所有方法签名而是建立“功能到方法”的索引。遇到“求绝对值”想到Math.abs遇到“复制数组”想到System.arraycopy遇到“生成随机数”想到Math.random形成了这个索引做题速度会明显提升。3. 从读题到提交手把手解题实操全流程3.1 做题三步法签名、注释、边界一个都不能少函数题的解题流程完全可以标准化我总结了一个三步法每次拿到题都按这个顺序执行效率和准确率都能稳定。第一步读签名。先盯着方法定义看十秒钟问自己三个问题方法名是什么参数有几个、各是什么类型返回值是什么类型这三个答案决定了后续所有代码的走向。比如方法签名是public static int countChar(String s, char c)那你要返回的就一定是一个int计算内容是统计字符c在字符串s中出现的次数。签名都没看清就急着写方法体是最常见的低级失误。第二步读注释。函数题的注释通常就是“出题人的意图说明书”里面往往写着最重要的行为约束。比如“若s为null返回0”“忽略大小写”“不包含空格”……这些句子少看一个隐藏测试用例就多一分击穿的风险。我习惯把注释里的关键约束条件提取到草稿纸上或者直接复制到代码注释里保证自己不会忘。第三步想边界。这一步是区分“写得出来”和“写得对”的分水岭。函数题的测试用例分为可见样例和隐藏用例隐藏用例专门挑你主流程没覆盖到的地方下手。拿到题后不要急着写核心逻辑先问参数可能是null吗可能是空串吗负数应该返回什么最大值会溢出吗这些边界想清楚再动笔。这三步看起来简单但实际做题时很多人会跳过第二步和第三步。我自己刷题经验里十个“答案错误”里至少有七个和边界有关真正因为核心算法写错的反而少。把这三步写进肌肉记忆相当于给OJ增加了一层保险。3.2 实操案例一字符串前缀处理String常用方法组合为了让你看清楚完整的解题链路我设计一道典型函数题和sdut常用类函数题的风格一致。实现StringUtil类的handle方法当字符串s以sdut-开头时返回去掉该前缀后的字符串否则返回原字符串。若s为null或空串返回空串。拿到方法先排定方案用startsWith判断前缀用substring截取剩余部分。再看边界条件注释明确说null和空串要返回空串所以开头必须先做判空。代码如下public static String handle(String s) { if (s null || s.isEmpty()) { return ; } if (s.startsWith(sdut-)) { return s.substring(5); } return s; }逐行分析一下。第一行判断null和空串注意先判断null再判断isEmpty顺序不能反否则null调用isEmpty会空指针异常。第二行用startsWith判断前缀参数是sdut-长度为5。第三行用substring(5)跳过前5个字符这里必须算准长度s-d-u-t-刚好是5个字符如果前缀写成sdut就是4一个字符之差直接决定答案对错。测试能覆盖的场景也很清晰。输入sdut-java返回java输入sdut-返回空串因为去掉5个字符后剩余长度为0substring(5)合法返回输入hello返回hello输入null返回。这四种情况分别对应了正常路径、边界前缀、无前缀、空值四种分支正好覆盖了判断题面的四个隐藏考点。我在这个题上还有一个独家小技巧本地自测时不要只跑题目给的样例要自己补几组“刁钻”输入。比如前缀只出现一半的字符串sdut它不以sdut-开头应该返回sdut本身这个用例能检查你前缀判断的严谨性。再比如字符串就是sdut-本身这个用例能检验substring在截取到空串时不抛异常。把这些额外用例跑通提交时的信心会大很多。3.3 实操案例二提取数字字符串StringBuilder场景再看一道需要用StringBuilder的题目这类题和在线评测平台的性能要求联系更紧密。实现extractDigits方法从给定字符串中提取所有数字字符按原顺序拼接成新字符串返回。如果没有数字字符返回空串入参为null也返回空串。初看这题一个朴素方案是遍历字符串用把数字字符拼接起来。比如遍历到char3就执行result 3。这个方案在字符串很短时没问题但一旦输入长度达到几千甚至几万就会产生大量中间String对象性能会很差。正确做法是用StringBuilderpublic static String extractDigits(String input) { if (input null || input.isEmpty()) { return ; } StringBuilder sb new StringBuilder(); for (int i 0; i input.length(); i) { char c input.charAt(i); if (c 0 c 9) { sb.append(c); } } return sb.toString(); }代码不长关键点在四个地方。第一是判空逻辑null和空串都返回空串。第二是字符判断c 0 c 9比调用Character.isDigit更直白范围判断在字符编码表上是连续的这个写法既高效又不容易出错。第三是拼接方式用StringBuilder的append在遍历过程中不断追加字符不会产生中间垃圾对象。第四是最后一定要调用toString()转换回String因为方法签名要求的返回类型是String不转换就会编译错误。这个题还有一个常见的变形要求提取数字后去重或者要求统计数字个数而不返回字符串。变形题的核心逻辑仍然是遍历、判断、存储这几步只是存储载体从StringBuilder变成了Set或者计数器。理解了StringBuilder在拼接场景的地位这类变形题基本可以顺手拿下。3.4 提交前的自检清单让评测一次通过写完之后不要立刻点提交先花三十秒做一遍自检我有六条清单按顺序问自己。第一方法签名是否完全一致。函数题的死穴是签名不匹配哪怕只是返回类型从String写成了StringBuilder或者是参数类型从String写成了CharSequence都可能直接编译失败。第二边界条件是否处理齐全。null、空串、负值、最大值这些在题面注释里有没有明确要求如果没写也要自己补上。第三字符串比较是否用了equals。写代码时扫一眼凡是字符串内容比较检查有没有误用。第四循环里有没有性能隐患。尤其检查String拼接如果有改写成StringBuilder。第五返回值是否齐全。所有分支都要有return语句编译器才不会报“缺少返回语句”。第六没有多余输出。函数题里多写一行println会导致OJ把输出和预期比对时直接判答案错误除非题目明确要求方法内部输出否则一律不要打印。这六条我称为“自检六连”每次在OJ上提交函数题之前过一遍能轻松过滤掉大半低级错误。真正的老手会把这套自检融入写代码的过程里写完即检提交就像喝水一样自然。4. 常见问题排查与避坑经验实录4.1 OJ三大错误类型速查表编译错误、答案错误、运行超时在OJ上刷题最磨人的不是不会做而是“做了但过不了”。不管是sdut还是其他在线评测平台函数题的报错通常集中在这么几类我用表格总结一下错误提示常见原因排查与解决办法编译错误方法签名写错、缺少return语句、用了不存在的类名、代码里有中文字符回看题目给的类名和方法名逐一比对检查所有分支是否都有return把中文全角符号全部换掉答案错误边界条件没处理、字符串用比较、substring边界算错、只实现了部分功能用自检六连排查本地额外补测null、空串、超长输入等隐藏用例运行超时循环里用拼接字符串、死循环、算法复杂度太高大循环拼接改StringBuilder检查循环变量是否推进思考是否有更低复杂度解法运行时异常空指针异常、数组越界、类型转换异常在判空和边界处打点debug确认substring和charAt的索引不越界包装类转换前先校验格式说实话OJ平台给出的错误提示往往很简略有些甚至只告诉你“答案错误”却不告诉你是哪一条用例挂的。这种时候最有效的排查手段不是在OJ上瞎猜而是回到本地IDE把自己的实现跑一遍把所有你能想到的边界输入都喂给它看哪一条输出和预期不一致。大多数“答案错误”都可以这样在本地被定位。有一个细节值得单独提醒部分函数题允许你在提交的代码里拥有额外的辅助方法但题目给的类名和方法签名必须原封不动。有些同学为了测试方便在方法体里写了main方法提交时忘了删结果类里出现了两个public方法或者main方法直接编译失败。提交前检查一下代码里只保留题目要求的类和最必要的方法不要夹带测试代码。4.2 我在做这类题时踩过的真实坑这些坑全是我当年在学Java时真实踩过的每一个都对应着一段线上评测“红色页面”的回忆。第一个坑是字符串内容比较用错。有一道反转字符串的题我需要判断反转前和反转后是否相等当时觉得StringBuffer的reverse完事之后直接比较就行本地跑通提交后答案错误。后来才明白内容相同的两个String对象可能是不同实例必须用equals或者equalsIgnoreCase。从那以后我养成了习惯只要看到字符串比较第一反应就是equals。第二个坑是substring的区间界限。有一次统计子串出现次数需要判断某个位置之后是否还剩指定长度的字符串我写的是if (i len s.length())边界差了一位导致最后一个可能匹配的子串被漏掉。这类问题根本不用猜直接把substring的源码语义背下来substring(beginIndex, endIndex)返回从beginIndex到endIndex的前一位即左闭右开的区间然后在实际使用中多验证边界位置。第三个坑是Integer的缓存陷阱这也是我前面提到过的经典坑。那年做一个判断两个整数是否相等的函数题我拿Integer c Integer d直接比较测试数据刚好都在-128到127之间就通过了我还挺高兴。结果换一批测试数据直接翻车一百多行代码看起来都对就是AC不了。当时花了整整一个晚上才定位到比较包装类这一点。之后我在这类题里彻底放弃了用比较两个包装对象一律equals或者拆箱。第四个坑是StringBuilder忘了toString。有一次我实现的方法返回类型是String我在方法末尾直接return sb;编译器立刻报错因为sb是StringBuilder类型。这个坑其实是好事编译错误比答案错误好查得多。但它提醒我StringBuilder只是一个中间容器永远记得最终要转成String交付给外部。第五个坑是循环字符串拼接导致超时。那是第一次遇到大数据的字符串拼接题输入长达几万字符我用result c拼了半天本地跑着还行一上OJ直接运行超时。后来的教训是只要拼接次数可能超过几十次就别用直接上StringBuilder。这个习惯我一直带到工作中处理日志拼接、SQL组装时都用builder几乎没再遇到过拼接性能问题。4.3 从函数题到面试题常用类学习的第二阶段函数题能帮你建立的更多是“会用”层面的能力但仅仅会做OJ题还不足以应对真正的面试因为面试官会把问题问到“为什么”的深度。这是学习常用类的第二阶段也是最容易拉开差距的阶段。先看面试的常见追问。String为什么设计成不可变的答案可以从安全性、线程安全、字符串常量池复用、hashCode缓存几个角度答随便展开一个方向都比只会背结论要强。StringBuilder是如何做到高效拼接的这就要说到内部字符数组和扩容机制默认容量是16扩容策略是旧容量乘2加2。Integer的缓存范围为什么是-128到127这是JVM规范建议的范围网络传输和数值统计里的小整数更常见缓存能有效减少对象创建。要把这些“为什么”学透我的建议是代码压缩包的深度阅读。打开IDE按住Ctrl点进StringBuilder源码你能看到append方法、扩容方法、toString方法的完整实现点进Integer源码你能看到valueOf方法里的缓存判断逻辑。不需要每个类都通读挑高频的几个类看核心方法就够了。看完再用小demo验证比如写个程序打印Integer缓存的边界现象这种“源码实验”的组合会让你记得非常牢。技术社区里关于Java基础、面向对象、常用类的文章和教程很多挑质量高的进行补充。比如可以搜Java面试题、Java八股文相关内容它们会把零散知识点串联成体系。但请注意直接背八股不如自己动手写几个验证demo把知识点转成自己的理解才是面试时能自信表达的基础。如果你现在还被sdut这类常用类函数题折腾其实是一件好事。这意味着你正在面向对象课程最关键的阶段筑基等这些题做完后面的集合类和IO流学习会顺很多。函数题不会白刷每一个查漏补缺的瞬间都在变成你面试时脱口而出的底气。最后再分享一个坚持了很多年的小习惯做函数题时我会把“应该处理哪些边界输入”直接写在代码注释里然后写完方法立刻测试五组数据——null、空串、一个字符、全数字、超长字符串。这五组能过基本就不会被隐藏用例击穿。这个习惯后来被我带进工作中写任何工具方法都先想边界花不了两分钟却能省下大量排查时间。常用类这波题做扎实了后面Java的学习会轻松很多。