在Java开发中，衡量一个方法随数据规模增长的执行开销，最核心的手段就是时间复杂度分析。很多人在写循环时纠结于到底是写成i < n还是i <= n，担心边界差一个单位就会让性能评估失效。实际上，时间复杂度关注的并不是精确的指令条数，而是输入规模n趋于无穷大时，执行时间随n变化的渐进趋势。
一、循环边界对执行次数的影响
我们先看一段最基础的累加代码。下面两个方法都用来计算从1到某个整数之和，区别仅在于循环条件的边界写法。
// 写法一：使用 i < n 作为边界
public static int sumByLess(int n) {
int total = 0;
for (int i = 0; i < n; i++) {
total += i;
}
return total;
}
// 写法二：使用 i <= n 作为边界
public static int sumByLessEqual(int n) {
int total = 0;
for (int i = 0; i <= n; i++) {
total += i;
}
return total;
}
在sumByLess中，循环变量i从0取到n-1，一共执行n次循环体；而在sumByLessEqual中，i从0取到n，一共执行n+1次。从精确计数角度看，后者确实比前者多做了一次加法。但在时间复杂度层面，两者都被归为O(n)，因为n+1和n在n很大时，比值趋近于1，常数差异被大O表示法抹平。
这种边界差异在实际工程中几乎不会成为性能瓶颈。比起纠结是否多一次循环，我们更该关注循环内部是否包含高开销操作，比如字符串拼接或数据库访问。如果循环体本身是O(1)的简单运算，那么无论边界是<还是<=，方法的渐进复杂度都不会脱离线性级别。
二、为什么O(n)不受常数倍干扰
大O符号的严格定义是：若存在常数c和n0，使得当n≥n0时，f(n)≤c·g(n)，则称f(n)为O(g(n))。放到我们的循环例子里，执行次数f(n)=n或n+1，我们总能找到c=2、n0=1，使得n+1≤2n成立，因此n+1属于O(n)。
// 即便循环体执行 3*n 次，依然为 O(n)
public static void printThrice(int n) {
for (int i = 0; i < n; i++) {
System.out.println(i);
System.out.println(i);
System.out.println(i);
}
}
上面这个方法里，每次外层循环打印三次，总指令数约为3n，但因为3是常数，该方法仍然被划分为O(n)。这也是为什么在面试或算法设计中，我们往往直接数“循环嵌套层数”而非精确语句数。
需要注意的是，如果循环边界本身依赖于数据内容而非固定规模，例如while (x < n * n)，那么执行次数会变成n²量级，此时边界虽只是条件表达式变化，复杂度却跃升为O(n²)。可见真正改变复杂度等级的是循环终止条件与n的数学关系，而非单纯的等号与否。
三、嵌套循环中的边界误区
当循环中再套循环时，初学者常误以为内层写j <= i会比j < i让整体复杂度升高。我们看一个双层循环示例。
// 内层边界为 j <= i
public static int nestedSumA(int n) {
int count = 0;
for (int i = 0; i < n; i++) {
for (int j = 0; j <= i; j++) {
count++;
}
}
return count;
}
// 内层边界为 j < i
public static int nestedSumB(int n) {
int count = 0;
for (int i = 0; i < n; i++) {
for (int j = 0; j < i; j++) {
count++;
}
}
return count;
}
方法A的内层执行次数为1+2+…+(n-1)+n，即n(n+1)/2；方法B为0+1+…+(n-1)，即n(n-1)/2。两者相差n次，但最高次项都是n²/2，因此都是O(n²)。在渐进分析里，低次项和常数系数全部忽略，只保留增长最快的项。
这种分析方式让我们能快速判断：只要外层循环跑n次、内层平均跑约n次，不管边界是否包含等号，整体就是平方级。若想优化，就得打破嵌套结构，比如用哈希表空间换时间，将内层查找降为O(1)，从而把方法整体降到O(n)。
四、实操：如何快速给Java方法算复杂度
拿到一段Java代码，建议按以下步骤估算。首先找最深、最外层循环变量与n的关系；其次看循环体是否含递归或集合操作；最后合并各部分的量级。
// 步骤示例：含列表遍历与条件跳出
public static boolean hasEven(List<Integer> list) {
for (int i = 0; i < list.size(); i++) {
if (list.get(i) % 2 == 0) {
return true; // 最好情况 O(1)，最坏情况 O(n)
}
}
return false;
}
上例最坏情况下要扫完整个列表，因此是O(n)；平均情况约为O(n/2)，仍记作O(n)。如果列表换成LinkedList且用get(i)随机访问，则每次get本身是O(n)，整体退化成O(n²)，这说明复杂度分析还要结合所用数据结构的底层实现。
总结来说，Java方法的时间复杂度分析重在看规模趋势。循环边界差一个单位、多一次常数操作，都不会让你从O(n)变成O(n²)。把精力放在减少嵌套层数、选对容器类型、避免隐式高阶操作上，才是控制复杂度的正道。