解决Hackerrank Java Map题目时的printf超时问题求助

嘿，这个问题我之前也碰到过类似的，来给你拆解一下核心原因！

首先，我们先对比两种写法的底层行为：

第一种写法（不超时） #

System.out.printf(search + "=" + phoneBook.get(search) + "\n");

你这里其实是先手动完成了字符串拼接，把search、=、电话号码和换行符拼成了一个完整的字符串，再传给printf。此时printf收到的格式字符串就是这个拼接好的完整内容，里面没有任何占位符（%s、%d这类），所以printf内部几乎不需要做额外的格式化工作——它本质上和直接调用System.out.println(拼接后的字符串)没什么区别，只是走了printf的方法入口而已，开销极低。

第二种写法（超时） #

System.out.printf("%s=%d\n", search, phoneBook.get(search));

这种写法依赖printf的格式化能力，它的底层流程要复杂得多：

1. 每次调用都要解析格式字符串%s=%d\n，识别里面的占位符类型和位置；
2. 匹配对应的参数，把search（字符串）适配到%s，把phoneBook.get(search)返回的Integer拆箱成int适配到%d；
3. 执行格式化拼接，生成最终的输出字符串。

这些步骤看起来单次开销不大，但Hackerrank的超时测试用例往往是超大循环量（比如几万甚至几十万次查询），每次循环都重复执行上面的解析、适配、格式化操作，累积起来的开销就会突破超时阈值。

额外补充：为什么差异这么明显？ #

Java的PrintStream.printf是基于Formatter实现的，而Formatter解析格式字符串的过程是有固定开销的——哪怕格式字符串完全一样，每次调用都会重新解析一遍（除非你手动缓存Formatter实例）。而手动拼接字符串的开销，其实是由StringBuilder（编译时会把+优化成StringBuilder.append）完成的，这个操作的开销比Formatter的格式化流程小得多，尤其是在循环次数极多的时候。

优化建议 #

如果想兼顾代码可读性和性能，可以试试这两种方式：

• 直接用System.out.println(search + "=" + phoneBook.get(search))，去掉printf的额外开销；
• 如果要批量输出，用StringBuilder把所有结果拼接好后一次性输出，减少IO次数（IO操作本身也是性能大户）。

内容的提问来源于stack exchange，提问作者user8858222