出于好奇，我试着对其进行基准测试……

import org.junit.Test;
import static org.junit.Assert.*;


public class TestStack1306727 {

    @Test
    public void bench(){
        int number=1000;
        int a= String.valueOf(number).length();
        int b= 1 + (int)Math.floor(Math.log10(number));

        assertEquals(a,b);
        int i=0;
        int s=0;
        long startTime = System.currentTimeMillis();
        for(i=0, s=0; i< 100000000; i++){
            a= String.valueOf(number).length();
            s+=a;
        }
        long stopTime = System.currentTimeMillis();
        long runTime = stopTime - startTime;
        System.out.println("Run time 1: " + runTime);
        System.out.println("s: "+s);
        startTime = System.currentTimeMillis();
        for(i=0,s=0; i< 100000000; i++){
            b= number==0?1:(1 + (int)Math.floor(Math.log10(Math.abs(number))));
            s+=b;
        }
        stopTime = System.currentTimeMillis();
        runTime = stopTime - startTime;
        System.out.println("Run time 2: " + runTime);
        System.out.println("s: "+s);
        assertEquals(a,b);


    }
}

结果如下:

Run time 1: 6765
s: 400000000
Run time 2: 6000
s: 400000000

现在我想知道我的基准测试是否真的意味着什么，但我确实在基准测试本身的多次运行中得到了一致的结果(一毫秒内的变化)……:)看起来这是无用的尝试和优化…

编辑:根据ptomli的注释，我在上面的代码中用' I '替换'number'，并在5次运行的bench中得到以下结果:

Run time 1: 11500
s: 788888890
Run time 2: 8547
s: 788888890

Run time 1: 11485
s: 788888890
Run time 2: 8547
s: 788888890

Run time 1: 11469
s: 788888890
Run time 2: 8547
s: 788888890

Run time 1: 11500
s: 788888890
Run time 2: 8547
s: 788888890

Run time 1: 11484
s: 788888890
Run time 2: 8547
s: 788888890

使用Java

int nDigits = Math.floor(Math.log10(Math.abs(the_integer))) + 1;

使用import java.lang.Math.*;一开始

使用C

int nDigits = floor(log10(abs(the_integer))) + 1;

在开始时使用include math.h

你的基于字符串的解决方案是完全OK的，没有什么“不整洁”的。你必须意识到，在数学上，数字没有长度，也没有数字。长度和数字都是数字在特定基底(即字符串)中的物理表示形式的属性。

基于对数的解决方案在内部完成(部分)与基于字符串的解决方案相同的工作，并且可能(微不足道地)更快，因为它只生成长度而忽略数字。但实际上我并不认为它的意图更明确——这是最重要的因素。

出于好奇，我试着对其进行基准测试……

import org.junit.Test;
import static org.junit.Assert.*;


public class TestStack1306727 {

    @Test
    public void bench(){
        int number=1000;
        int a= String.valueOf(number).length();
        int b= 1 + (int)Math.floor(Math.log10(number));

        assertEquals(a,b);
        int i=0;
        int s=0;
        long startTime = System.currentTimeMillis();
        for(i=0, s=0; i< 100000000; i++){
            a= String.valueOf(number).length();
            s+=a;
        }
        long stopTime = System.currentTimeMillis();
        long runTime = stopTime - startTime;
        System.out.println("Run time 1: " + runTime);
        System.out.println("s: "+s);
        startTime = System.currentTimeMillis();
        for(i=0,s=0; i< 100000000; i++){
            b= number==0?1:(1 + (int)Math.floor(Math.log10(Math.abs(number))));
            s+=b;
        }
        stopTime = System.currentTimeMillis();
        runTime = stopTime - startTime;
        System.out.println("Run time 2: " + runTime);
        System.out.println("s: "+s);
        assertEquals(a,b);


    }
}

结果如下:

Run time 1: 6765
s: 400000000
Run time 2: 6000
s: 400000000

现在我想知道我的基准测试是否真的意味着什么，但我确实在基准测试本身的多次运行中得到了一致的结果(一毫秒内的变化)……:)看起来这是无用的尝试和优化…

编辑:根据ptomli的注释，我在上面的代码中用' I '替换'number'，并在5次运行的bench中得到以下结果:

Run time 1: 11500
s: 788888890
Run time 2: 8547
s: 788888890

Run time 1: 11485
s: 788888890
Run time 2: 8547
s: 788888890

Run time 1: 11469
s: 788888890
Run time 2: 8547
s: 788888890

Run time 1: 11500
s: 788888890
Run time 2: 8547
s: 788888890

Run time 1: 11484
s: 788888890
Run time 2: 8547
s: 788888890

下面是JDK开发人员给出的解决方案。JDK 17 (Long类):

/**
 * Returns the string representation size for a given long value.
 *
 * @param x long value
 * @return string size
 *
 * @implNote There are other ways to compute this: e.g. binary search,
 * but values are biased heavily towards zero, and therefore linear search
 * wins. The iteration results are also routinely inlined in the generated
 * code after loop unrolling.
 */
static int stringSize(long x) {
    int d = 1;
    if (x >= 0) {
        d = 0;
        x = -x;
    }
    long p = -10;
    for (int i = 1; i < 19; i++) {
        if (x > p)
            return i + d;
        p = 10 * p;
    }
    return 19 + d;
}

注意，如果需要的话，该方法会考虑减号。

不幸的是，该方法没有公开。

在性能方面，您可以从评论中看到，JDK开发人员与其他选项相比至少考虑了这一点。我猜 分而治之的方法倾向于较小的数字，效果会稍好一些 更好，因为CPU可以比整数更快地进行整数比较 乘法。但这种差异可能小到无法测量。

无论如何，我希望JDK中已经公开了这个方法，这样人们就不会开始使用自己的方法了。

一个人想要这样做主要是因为他/她想要“呈现”它，这主要意味着它最终需要显式或隐式地“toString-ed”(或以另一种方式转换);才能呈现(例如打印出来)。如果是这种情况，那么只需尝试显式地使用必要的“toString”并计算位数。