字符串连接的使用效率低下
我正在我的java-app中创建一个记录器（使用NetBeans作为IDE）突然我看到一个警告说：“在记录器中使用字符串连接效率低下”。
我的oringinal代码是
srcLogger.getLogger().log(Level.INFO,"UploadBean.doUpload completado [" + file.getName() + "]\n"); 但NetBeans建议将其转换为模板（这里的“模板”是什么意思？）给出以下代码：
srcLogger.getLogger().log(Level.INFO, "UploadBean.doUpload completado [{0}]\n", file.getName());
这两种连接方式有什么不同，我从来没有使用过后者。
干杯。
我会忽略警告（如果可能的话，如果它关闭则切换）。 连接并不是那么低效，因为现代编译StringBuilder基于StringBuilder的高效实现替换它（如果查看类文件的字节码，你会看到它）。
建议的替换不会连接字符串，但它需要一些额外的处理来解析模板并将其与参数合并。
Netbeans，这是一个糟糕的建议。
这适用于Java 1.5+。 旧版本的Java（可能）在连接期间创建了许多未使用的String实例。
该消息不是指字符串连接本身的代价。 当他们说将使用StringBuilder时，其他答案是完全正确的。
使用消息模板的主要原因是因为只在显示日志记录级别时才进行处理！
让我们使用这两个例子：
srcLogger.getLogger().log(Level.INFO,"UploadBean.doUpload completado [" + file.getName() + "]\n"); srcLogger.getLogger().log(Level.INFO, "UploadBean.doUpload completado [{0}]\n", file.getName());
启用调试级别INFO：两者都必须从File获取文件名，两者都必须更新字符串，生成一个新的字符串，显示它。
调试级别INFO关闭：第二个答案通过File对象的名称（这是一个简单的查询），log（）方法检查INFO级别并立即返回。 根本不执行String处理！
现在想象一下，我们记录的是一个更复杂的对象，而不是简单的file.getName() ，它本身需要在toString()方法中进行大量的字符串连接。 通过直接记录这些对象，根本不会完成任何处理。 除非显示调试级别，否则甚至不会调用toString() 。
因此，在显示日志记录的情况下，消息模板不是更有效，但是当未显示日志记录时，它非常有效（特别是在非平凡日志记录的情况下）。 日志记录的目标之一应该是，如果关闭日志记录，则它对系统性能的影响最小。
这里真正的胜利是，如果记录器配置为不在INFO级别登录，则根本不需要进行任何字符串处理（连接或模板扩展）。
也就是说，记录器可以决定什么也不做，而不必去任何类型的字符串操作。
由于字符串在Java中是不可变的，因此当您连接String对象时，实际上会创建一个全新的对象。 使用类似Netbeans建议的模板或StringBuilder可以防止您创建所有这些需要时间和资源的中间对象。
模板意味着，它应该是String的模板，而不是String本身。 我们的想法是{0}位将被替换为列表中的第一个参数（ file.getName() ）。 这遵循String的format方法的模式。
我没有看到任何性能测试来validation这是否更快。 正如其他答案所指出的那样离开它并不会特别慢，因为编译器将使用StringBuilder代替常规String。 但是，正如@dty指出的那样，我认为在设置日志记录级别以便实际不记录语句的情况下应该更快，因为构造要输出的字符串不需要任何工作。 此外，由于整个模板字符串是单个文字，因此编译器会将其添加到字符串池中。 这意味着这个特定String所有实例都将指向同一个实际实例 – 所以如果该语句实际上没有被记录，那么它甚至不必分配内存来存储这个字符串，它只是查找它，它应该是更高效。
您从NetBeans获得的警告为您提供了避免在日志语句中连接的最短理由。
- 使用模板样式时，不会构建不会发送到日志的日志消息。 您甚至可以通过避免参数列表中的方法调用来更优化样式。
但是还有一些其他原因可以选择将模板样式用于日志消息。
一个。 避免concat的可能开销。 正如其他人所指出的那样，这对于最近的javac来说并不是一个大问题。
湾 您的代码为国际化/本地化做好了更充分的准备。 虽然你可能会认为…这段代码永远不会需要那么高的关注度……令人惊讶的是代码在最初编写之后会走多远。