这个问题在这里已经有答案了：
8年前关门了。
可能重复：
for循环优化
假设我们要循环一个字符串的字符 s . 我认为下面的代码或多或少是默认的。
for( int i = 0; i < s.length(); i++ ) {
doSomethingWith( s.charAt( i ) );
}问题#1：为什么我经常看到以下情况？
final int length = s.length();
for( int i = 0; i < length; i++ ) {
doSomethingWith( s.charAt( i ) );
}乍一看，这似乎是合理的，因为不等式是在每次迭代中计算的。不过，我还是希望vm能够对此进行优化，因为字符串是不可变的。有什么想法吗？如果我们迭代一个可变的结构（它没有被任何其他线程引用），会怎么样？如果 length() 不保证在o（1）中运行？
问题2：有些人似乎认为 ++i 为了 i++ 加速代码。他们说的对吗？同样，这不是我所期望的，但我只是不确定。
我们都知道不要过早地优化。同时，如果我们能以几乎没有任何代价产生稍微快一点的代码，我们不这样做是愚蠢的。当然，有人会说这两种“优化”都会损害可读性，但在我看来，这种损害非常小，在某些情况下是合理的。
我试着去衡量表现上的差异，但很难得出结论性的结果。虽然这应该解决它的任何具体应用，我的目标是洞察和一般的答案在这里。
（尽管我写这篇文章时考虑到了热点虚拟机，但考虑其他平台（如移动设备）也可能很有趣。）
2条答案
按热度按时间wnrlj8wa1#
乍一看，这似乎是合理的，因为不等式是在每次迭代中计算的。不过，我还是希望vm能够对此进行优化，因为字符串是不可变的。
编译器对此进行了优化。像这样做
i < s.length();很好。有些人似乎认为用i替换i可以加快代码的速度。
它不会，除非你给++i的返回值赋值
8wigbo562#
问题#1：为什么我经常看到以下情况？
第一个例子是过早的优化。人们这样做的原因是，他们通常不会分析自己的代码以了解真正的瓶颈在哪里，而只是尝试猜测。
如果length（）不能保证在o（1）中运行呢？
那么进行这种优化就更有意义了。如果您知道计算长度是一个昂贵的操作，并且值不会更改，那么计算一次并存储结果可能会提高性能。
问题2：有些人似乎认为用i代替i可以加快代码的速度。他们说的对吗？同样，这不是我所期望的，但我只是不确定。
他们不对。他们的论点是
i++必须创建变量的临时副本++i没有。在很久以前，当编译器不擅长优化时，这在c或c++中是真实的。这对于java来说是不正确的。