题

假设您有一个大的 ASCII 文本文件，每行都有一个随机的非负整数，每行的范围从 0 到 1,000,000,000。文件中有 100,000,000 行。阅读文件并计算所有整数之和的最快方法是什么？

约束：我们有 10MB 的 RAM 可以使用。该文件大小为 1GB，因此我们不想读取整个内容然后对其进行处理。

这是我尝试过的各种解决方案。我发现结果相当令人惊讶。

有什么我错过的更快的东西吗？

请注意：下面给出的所有时间都是为总共运行算法10 次（运行一次并丢弃；启动计时器；运行 10 次；停止计时器）。该机器是相当慢的Core 2 Duo。

方法一：自然法

首先要尝试的是显而易见的方法：

private long sumLineByLine() throws NumberFormatException, IOException {
    BufferedReader br = new BufferedReader(new FileReader(file));
    String line;
    long total = 0;
    while ((line = br.readLine()) != null) {
        int k = Integer.parseInt(line);
        total += k;
    }
    br.close();
    return total;
}

请注意，最大可能的返回值是 10^17，它仍然很容易放入 a 中long，因此我们不必担心溢出。

在我的机器上，运行 11 次并扣除第一次运行大约需要92.9 秒。

方法二：微调

受到对这个问题的评论的启发，我尝试不创建一个新的int k来存储解析该行的结果，而只是将解析的值直接添加到total. 所以这：

    while ((line = br.readLine()) != null) {
        int k = Integer.parseInt(line);
        total += k;
    }

变成这样：

    while ((line = br.readLine()) != null)
        total += Integer.parseInt(line);

我确信这不会有任何区别，并且认为编译器很可能会为两个版本生成相同的字节码。但是，令我惊讶的是，它确实缩短了一点时间：我们减少到92.1 秒。

方法三：手动解析整数

到目前为止，代码中让我困扰的一件事是我们将String转换为int，然后在最后添加它。在我们进行时添加会不会更快？如果我们String自己解析会发生什么？像这样的东西...

private long sumLineByLineManualParse() throws NumberFormatException,
        IOException {
    BufferedReader br = new BufferedReader(new FileReader(file));
    String line;
    long total = 0;
    while ((line = br.readLine()) != null) {
        char chs[] = line.toCharArray();
        int mul = 1;
        for (int i = chs.length - 1; i >= 0; i--) {
            char c = chs[i];
            switch (c) {
            case '0':
                break;
            case '1':
                total += mul;
                break;
            case '2':
                total += (mul << 1);
                break;
            case '4':
                total += (mul << 2);
                break;
            case '8':
                total += (mul << 3);
                break;
            default:
                total += (mul*((byte) c - (byte) ('0')));   
            }
            mul*=10;
        }
    }
    br.close();
    return total;
}

我认为，这可能会节省一点时间，尤其是对进行乘法的一些位移优化。但是转换为字符数组的开销必须淹没任何收益：现在需要148.2 秒。

方法四：二进制处理

我们可以尝试的最后一件事是将文件作为二进制数据进行处理。

如果你不知道它的长度，从前面解析一个整数是很尴尬的。向后解析要容易得多：您遇到的第一个数字是单位，下一个是十，依此类推。因此，解决整个问题的最简单方法是向后读取文件。

如果我们分配一个byte[]（比如）8MB的缓冲区，我们可以用文件的最后 8MB 填充它，处理它，然后读取前面的 8MB，依此类推。我们需要小心一点，当我们移动到下一个块时，我们不要搞砸我们正在解析的数字，但这是唯一的问题。

当我们遇到一个数字时，我们将它（根据它在数字中的位置适当地相乘）加到总数中，然后将系数乘以 10，这样我们就为下一个数字做好了准备。如果我们遇到任何不是数字的东西（CR 或 LF），我们只需重置系数。

private long sumBinary() throws IOException {
    RandomAccessFile raf = new RandomAccessFile(file, "r");
    int lastRead = (int) raf.length();
    byte buf[] = new byte[8*1024*1024];
    int mul = 1;
    long total = 0;
    while (lastRead>0) {
        int len = Math.min(buf.length, lastRead);
        raf.seek(lastRead-len);
        raf.readFully(buf, 0, len);
        lastRead-=len;
        for (int i=len-1; i>=0; i--) {
            //48 is '0' and 57 is '9'
            if ((buf[i]>=48) && (buf[i]<=57)) {
                total+=mul*(buf[i]-48);
                mul*=10;
            } else
                mul=1;
        }
    }
    raf.close();
    return total;
}

这在30.8 秒内运行！这是一个由3倍的速度增长较前最好。

后续问题

为什么这么快？我原以为它会赢，但并没有那么令人印象深刻。主要是转换为 a 的开销String吗？以及有关字符集之类的所有幕后担忧？
我们可以通过使用 aMappedByteBuffer来帮助做得比这更好吗？我有一种感觉，调用从缓冲区读取的方法的开销会减慢速度，尤其是从缓冲区向后读取时。
向前读取文件而不是向后读取文件，但仍然向后扫描缓冲区会更好吗？这个想法是你读取文件的第一个块，然后向后扫描，但最后丢弃半数。然后，当您读取下一个块时，您设置偏移量，以便从您丢弃的数字的开头读取。
有什么我没有想到的可以产生重大影响的吗？

更新：更令人惊讶的结果

首先，观察。我以前应该想到，但我认为String基于 -based 的读取效率低下的原因不是创建所有String对象所花费的时间太多，而是它们的寿命如此之短：我们有 100,000,000 个它们供垃圾收集器处理。那肯定会让它心烦意乱。

现在一些基于人们发布的答案/评论的实验。

我在欺骗缓冲区的大小吗？

一个建议是，由于 aBufferedReader使用了 16KB 的默认缓冲区，而我使用了 8MB 的缓冲区，因此我不会将 like 与 like 进行比较。如果您使用更大的缓冲区，它肯定会更快。

这是震惊。该sumBinary()方法（方法 4）昨天使用 8MB 缓冲区在 30.8 秒内运行。今天，代码不变，风向变了，我们在 30.4 秒。如果我将缓冲区大小降低到 16KB 以查看它变慢了多少，它会变快！现在运行时间为23.7 秒。疯狂的。谁看到那个来了？！

一些实验表明 16KB 大约是最佳的。也许 Java 人做了同样的实验，这就是为什么他们选择了 16KB！

问题是否受 I/O 限制？

我也想过这个问题。在磁盘访问上花费了多少时间，在数字运算上花费了多少时间？如果几乎所有的磁盘访问都如对建议的答案之一得到充分支持的评论所建议的那样，那么无论我们做什么，我们都无法做出太大的改进。

通过在注释掉所有解析和数字运算的情况下运行代码，这很容易测试，但读取仍然完好无损：

private long sumBinary() throws IOException {
    RandomAccessFile raf = new RandomAccessFile(file, "r");
    int lastRead = (int) raf.length();
    byte buf[] = new byte[16 * 1024];
    int mul = 1;
    long total = 0;
    while (lastRead > 0) {
        int len = Math.min(buf.length, lastRead);
        raf.seek(lastRead - len);
        raf.readFully(buf, 0, len);
        lastRead -= len;
        /*for (int i = len - 1; i >= 0; i--) {
            if ((buf[i] >= 48) && (buf[i] <= 57)) {
                total += mul * (buf[i] - 48);
                mul *= 10;
            } else
                mul = 1;
        }*/
    }
    raf.close();
    return total;
}

这现在在3.7 秒内运行！这对我来说似乎不是 I/O 绑定的。

当然，部分 I/O 速度将来自磁盘缓存命中。但这并不是真正的重点：我们仍然占用了 20 秒的 CPU 时间（也使用 Linux 的time命令进行了确认），这足以尝试减少它。

向前扫描而不是向后扫描

我在我的原始帖子中坚持认为有充分的理由向后而不是向前扫描文件。我没有很好地解释这一点。这个想法是，如果你向前扫描一个数字，你必须累加扫描数字的总值，然后把它加起来。如果向后扫描，则可以随时将其添加到累积总数中。我的潜意识正在对自己产生某种意义（稍后会详细说明），但我错过了一个关键点，这是在其中一个答案中指出的：向后扫描，我每次迭代进行两次乘法，但是向前扫描你只需要一个。所以我编写了一个前向扫描版本：

private long sumBinaryForward() throws IOException {
    RandomAccessFile raf = new RandomAccessFile(file, "r");
    int fileLength = (int) raf.length();
    byte buf[] = new byte[16 * 1024];
    int acc = 0;
    long total = 0;
    int read = 0;
    while (read < fileLength) {
        int len = Math.min(buf.length, fileLength - read);
        raf.readFully(buf, 0, len);
        read += len;
        for (int i = 0; i < len; i++) {
            if ((buf[i] >= 48) && (buf[i] <= 57))
                acc = acc * 10 + buf[i] - 48;
            else {
                total += acc;
                acc = 0;
            }
        }
    }
    raf.close();
    return total;
}

这在20.0 秒内运行，比向后扫描版本高出一段距离。好的。

乘法缓存

然而，我在晚上意识到，虽然我每次迭代执行两次乘法，但有可能使用缓存来存储这些乘法，这样我就可以避免在向后迭代期间执行它们。当我醒来时，我很高兴看到有人有同样的想法！

关键是我们正在扫描的数字中最多有 10 位数字，并且只有 10 位可能的数字，因此数字值对累积总数的可能性只有 100 种。我们可以预先计算这些，然后在向后扫描代码中使用它们。这应该优于前向扫描版本，因为我们现在已经完全摆脱了乘法。（请注意，我们不能通过前向扫描来做到这一点，因为乘法是累加器的，它可以取任何值直到 10^9。只有在后向情况下，两个操作数都被限制为几种可能性。）

private long sumBinaryCached() throws IOException {
    int mulCache[][] = new int[10][10];
    int coeff = 1;
    for (int i = 0; i < 10; i++) {
        for (int j = 0; j < 10; j++)
            mulCache[i][j] = coeff * j;
        coeff *= 10;
    }

    RandomAccessFile raf = new RandomAccessFile(file, "r");
    int lastRead = (int) raf.length();
    byte buf[] = new byte[16 * 1024];
    int mul = 0;
    long total = 0;
    while (lastRead > 0) {
        int len = Math.min(buf.length, lastRead);
        raf.seek(lastRead - len);
        raf.readFully(buf, 0, len);
        lastRead -= len;
        for (int i = len - 1; i >= 0; i--) {
            if ((buf[i] >= 48) && (buf[i] <= 57))
                total += mulCache[mul++][buf[i] - 48];
            else
                mul = 0;
        }
    }
    raf.close();
    return total;
}

这在26.1 秒内运行。令人失望，至少可以说。向后读取在 I/O 方面效率较低，但我们已经看到 I/O 并不是这里的主要问题。我原以为这会产生很大的积极影响。也许数组查找与我们替换的乘法一样昂贵。（我确实尝试将数组设为 16x16，并使用位移来索引，但没有帮助。）

看起来前向扫描就在那里。

使用 MappedByteBuffer

接下来要添加的是 a MappedByteBuffer，看看这是否比使用 raw 更有效RandomAccessFile。它不需要对代码进行太多更改。

private long sumBinaryForwardMap() throws IOException {
    RandomAccessFile raf = new RandomAccessFile(file, "r");
    byte buf[] = new byte[16 * 1024];
    final FileChannel ch = raf.getChannel();
    int fileLength = (int) ch.size();
    final MappedByteBuffer mb = ch.map(FileChannel.MapMode.READ_ONLY, 0,
            fileLength);
    int acc = 0;
    long total = 0;
    while (mb.hasRemaining()) {
        int len = Math.min(mb.remaining(), buf.length);
        mb.get(buf, 0, len);
        for (int i = 0; i < len; i++)
            if ((buf[i] >= 48) && (buf[i] <= 57))
                acc = acc * 10 + buf[i] - 48;
            else {
                total += acc;
                acc = 0;
            }
    }
    ch.close();
    raf.close();
    return total;
}

这似乎确实有所改善：我们现在是19.0 秒。我们的个人最好成绩又慢了一秒！

多线程呢？

建议的答案之一涉及使用多个内核。我有点惭愧，我没有想到这一点！

答案是有道理的，因为假设这是一个 I/O 限制的问题。鉴于 I/O 的结果，这似乎有点苛刻！无论如何，当然值得一试。

我们将使用 fork/join 来做到这一点。这是一个表示对文件的一部分进行计算的结果的类，请记住，左侧可能有部分结果（如果我们从数字的一半开始），右侧可能有部分结果（如果缓冲区完成了一个数字的一半）。该类还有一个方法允许我们将两个这样的结果粘合在一起，成为两个相邻子任务的组合结果。

private class SumTaskResult {
    long subtotal;
    int leftPartial;
    int leftMulCount;
    int rightPartial;

    public void append(SumTaskResult rightward) {
        subtotal += rightward.subtotal + rightPartial
                * rightward.leftMulCount + rightward.leftPartial;
        rightPartial = rightward.rightPartial;
    }
}

现在是关键位：RecursiveTask计算结果的。对于小问题（小于64个字符），调用computeDirectly()单线程计算结果；对于较大的问题，它分成两部分，在单独的线程中解决两个子问题，然后合并结果。

private class SumForkTask extends RecursiveTask<SumTaskResult> {

    private byte buf[];
    // startPos inclusive, endPos exclusive
    private int startPos;
    private int endPos;

    public SumForkTask(byte buf[], int startPos, int endPos) {
        this.buf = buf;
        this.startPos = startPos;
        this.endPos = endPos;
    }

    private SumTaskResult computeDirectly() {
        SumTaskResult result = new SumTaskResult();
        int pos = startPos;

        result.leftMulCount = 1;

        while ((buf[pos] >= 48) && (buf[pos] <= 57)) {
            result.leftPartial = result.leftPartial * 10 + buf[pos] - 48;
            result.leftMulCount *= 10;
            pos++;
        }

        int acc = 0;
        for (int i = pos; i < endPos; i++)
            if ((buf[i] >= 48) && (buf[i] <= 57))
                acc = acc * 10 + buf[i] - 48;
            else {
                result.subtotal += acc;
                acc = 0;
            }

        result.rightPartial = acc;
        return result;
    }

    @Override
    protected SumTaskResult compute() {
        if (endPos - startPos < 64)
            return computeDirectly();
        int mid = (endPos + startPos) / 2;
        SumForkTask left = new SumForkTask(buf, startPos, mid);
        left.fork();
        SumForkTask right = new SumForkTask(buf, mid, endPos);
        SumTaskResult rRes = right.compute();
        SumTaskResult lRes = left.join();
        lRes.append(rRes);
        return lRes;
    }

}

请注意，这是对 a 进行操作byte[]，而不是整个MappedByteBuffer。这样做的原因是我们希望保持磁盘访问顺序。我们将采用相当大的块，分叉/加入，然后移动到下一个块。

这是这样做的方法。请注意，我们已将缓冲区大小推高至 1MB（之前是次优的，但似乎在这里更明智）。

private long sumBinaryForwardMapForked() throws IOException {
    RandomAccessFile raf = new RandomAccessFile(file, "r");
    ForkJoinPool pool = new ForkJoinPool();

    byte buf[] = new byte[1 * 1024 * 1024];
    final FileChannel ch = raf.getChannel();
    int fileLength = (int) ch.size();
    final MappedByteBuffer mb = ch.map(FileChannel.MapMode.READ_ONLY, 0,
            fileLength);
    SumTaskResult result = new SumTaskResult();
    while (mb.hasRemaining()) {
        int len = Math.min(mb.remaining(), buf.length);
        mb.get(buf, 0, len);
        SumForkTask task = new SumForkTask(buf, 0, len);
        result.append(pool.invoke(task));
    }
    ch.close();
    raf.close();
    pool.shutdown();
    return result.subtotal;
}

现在这是令人心碎的失望：这个漂亮的多线程代码现在需要32.2 秒。为何这么慢？我花了很长时间调试这个，假设我做了一些非常错误的事情。

原来只需要一个小的调整。我认为小问题和大问题之间的阈值 64 是合理的；事实证明这完全是荒谬的。

像这样想。子问题的大小完全相同，因此它们应该在几乎相同的时间内完成。因此，与可用处理器数量相比，拆分成更多的部分实际上毫无意义。在我使用的只有两个内核的机器上，降低到 64 的阈值是荒谬的：它只会增加更多的开销。

现在您不想限制事情，以便即使有更多可用内核，它也只使用两个内核。或许正确的做法是找出运行时的处理器数量，然后将其拆分为多个部分。

在任何情况下，如果我将阈值更改为 512KB（缓冲区大小的一半），它现在会在13.3 秒内完成。降低到 128KB 或 64KB 将允许使用更多内核（分别最多 8 或 16 个），并且不会显着影响运行时间。

所以多线程确实有很大的不同。

这是一段相当长的旅程，但我们开始时用了 92.9 秒，现在缩短到 13.3 秒……这是原始代码速度的七倍。这不是通过改进渐近（大哦）时间复杂度，它从一开始就是线性（最佳）......这一切都是为了改进常数因子。

辛苦了一天。

我想我应该接下来尝试使用 GPU ......

后记：生成随机数文件

我使用以下代码生成了随机数，我运行并重定向到一个文件。显然，我不能保证你最终会得到与我完全相同的随机数:)

public static void genRandoms() {
    Random r = new Random();
    for (int i = 0; i < 100000000; i++)
        System.out.println(r.nextInt(1000000000));
}

IT小君

您的主要瓶颈将是文件 IO。解析和添加数字不应该对算法有贡献，因为这可以在文件 I/O 等待磁盘时在单独的线程中完成。

几年前，我研究了如何以最快的方式读取文件，并遇到了一些很好的建议 - 我将其作为扫描例程实现，如下所示：

// 4k buffer size.
static final int SIZE = 4 * 1024;
static byte[] buffer = new byte[SIZE];

// Fastest because a FileInputStream has an associated channel.
private static void ScanDataFile(Hunter p, FileInputStream f) throws FileNotFoundException, IOException {
    // Use a mapped and buffered stream for best speed.
    // See: http://nadeausoftware.com/articles/2008/02/java_tip_how_read_files_quickly
    final FileChannel ch = f.getChannel();
    long red = 0L;
    do {
        final long read = Math.min(Integer.MAX_VALUE, ch.size() - red);
        final MappedByteBuffer mb = ch.map(FileChannel.MapMode.READ_ONLY, red, read);
        int nGet;
        while (mb.hasRemaining() && p.ok()) {
            nGet = Math.min(mb.remaining(), SIZE);
            mb.get(buffer, 0, nGet);
            for (int i = 0; i < nGet && p.ok(); i++) {
                p.check(buffer[i]);
                //size += 1;
            }
        }
        red += read;
    } while (red < ch.size() && p.ok());
    // Finish off.
    p.close();
    ch.close();
    f.close();
}

您可能希望在测试速度之前调整此技术，因为它使用称为 a 的接口对象Hunter来寻找数据。

如您所见，该建议源自 2008 年，从那时起对 Java 进行了许多改进，因此这可能不会提供改进。

添加

我尚未对此进行测试，但这应该适合您的测试并使用相同的技术：

class Summer {

    long sum = 0;
    long val = 0;

    public void add(byte b) {
        if (b >= '0' && b <= '9') {
            val = (val * 10) + (b - '0');
        } else {
            sum += val;
            val = 0;
        }
    }

    public long getSum() {
        return sum + val;
    }
}

private long sumMapped() throws IOException {
    Summer sum = new Summer();
    FileInputStream f = new FileInputStream(file);
    final FileChannel ch = f.getChannel();
    long red = 0L;
    do {
        final long read = Math.min(Integer.MAX_VALUE, ch.size() - red);
        final MappedByteBuffer mb = ch.map(FileChannel.MapMode.READ_ONLY, red, read);
        int nGet;
        while (mb.hasRemaining()) {
            nGet = Math.min(mb.remaining(), SIZE);
            mb.get(buffer, 0, nGet);
            for (int i = 0; i < nGet; i++) {
                sum.add(buffer[i]);
            }
        }
        red += read;
    } while (red < ch.size());
    // Finish off.
    ch.close();
    f.close();
    return sum.getSum();
}

2021-10-19T04:49:57 回复

为什么这么快？

创建一个字符串比一点数学要贵得多。

我们可以通过使用 MappedByteBuffer 帮助做得比这更好吗？

一点，是的。它是我使用的。它将内存保存到内存副本。即不需要字节[]。

我有一种感觉，调用从缓冲区读取的方法的开销会减慢速度，

如果方法很简单，就会被内联。

特别是从缓冲区向后读取时。

它不会更慢，实际上向前解析更简单/更快，因为您使用一个*而不是两个。

向前读取文件而不是向后读取文件，但仍然向后扫描缓冲区会更好吗？

我不明白你为什么需要向后阅读。

这个想法是你读取文件的第一个块，然后向后扫描，但最后丢弃半数。然后，当您读取下一个块时，您设置偏移量，以便从您丢弃的数字的开头读取。

听起来不必要地复杂。我会一次性读取整个文件中的内存映射。除非文件大小超过 2 GB，否则无需使用块。即便如此，我也会一口气读完。

有什么我没有想到的可以产生重大影响的吗？

如果数据在磁盘缓存中，它会比其他任何东西都产生更大的不同。

您可以使用更大的缓冲区大小，以及更快地编码到字符串（到 Unicode）。

BufferedReader br = new BufferedReader(new InputStreamReader(
        new FileInputStream(file), StandardCharsets.US_ASCII),
        1_024_000_000);

您通过使用二进制 InputStream/RandomAccessFile 消除字符串使用的方法是值得的。

那么如果源文件被压缩也可能会很好。在 Unix 下，人们会选择 gzip 格式，其中xxx.txt.gz解压缩为xxx.txt. 这将是可读的GZipInputStream。它的优点是总体上加快了与服务器目录之间的文件传输速度。

我认为还有另一种方法可以做到这一点。

这是经典的多进程编程问题。在 C 语言中有库 MPI 可以解决此类问题。

它的想法是将整数列表分成 4 个部分，每个部分由不同的过程求和。完成后，流程汇总在一起。

在 Java 中，这可以通过线程（伪并行）和 Java 并发来完成。

例如，4 个不同的线程汇总了列表的 4 个不同部分。最后将它们相加。

电话公司使用执行这种并行编程技术的网格计算机来总结他们的交易。

这里唯一的问题（瓶颈）是 IO 操作。读取文件需要很长时间。如果以某种方式可以让多个线程读取文件的不同部分......这是非常复杂的方法，我认为这不会有多大好处，因为磁盘不会因为它被多个线程使用而旋转得更快，但是有做类似事情的其他技术。您可以在此处阅读更多相关信息：通过多线程访问文件和此处使用多线程读取单个文件：应该加快速度吗？

2021-10-19T04:49:58 回复

来源：http : //nadeausoftware.com/articles/2008/02/java_tip_how_read_files_quickly

为了获得最佳的 Java 读取性能，需要记住四件事：

通过一次读取一个数组而不是一次读取一个字节来最小化 I/O 操作。一个 8 KB 的数组是一个很好的大小。

通过一次获取一个数组而不是一个字节的数据来最小化方法调用。使用数组索引来获取数组中的字节。

如果不需要线程安全，请尽量减少线程同步锁。要么减少对线程安全类的方法调用，要么使用非线程安全类，如 FileChannel 和 MappedByteBuffer。

最大限度地减少 JVM/OS、内部缓冲区和应用程序阵列之间的数据复制。将 FileChannel 与内存映射或直接或包装的数组 ByteBuffer 一起使用。

基于此评论：“简单地总结所有字节会更快”，我提出了已接受答案的变体。

已接受的答案建议将问题分解为多个块，使用多线程计算每个卡盘的总和，最后将它们加在一起。

这个想法可以用来将后向扫描中的乘法次数减少到 O(1)，无需任何表查找和线程（或将其与线程结合）。只需利用乘法在加法上的分配方式，将所有个位添加到一个累加器中，将十位添加到一个单独的一个中，将成百上千位添加到它们自己的累加器中。这不需要任何乘法。

也可以使用 per-place 累加器来完成合并来自多个线程的结果的 reduce 步骤。计算总数的最后一步将需要乘法（或利用 10 只设置两位并使用位移和加法这一事实），但只有 9 次乘法就足够了。

这里有几个问题。

任何基于阅读行的解决方案都会对每个字符进行两次处理。例如，编译器不会这样做，它们一次读取一个字符并直接发送它。
任何基于的解决方案readLine()都将创建字符串。
您正在使用不同的缓冲区大小。
您正在使用不同的 I/O 技术。
在某些情况下，您正在使用字符转换，而在其他情况下则不是。
你过度分析了文件。你并不真正关心空白在哪里，或者有多少，只要它把数字彼此分开。

我的解决方案：

    BufferedInputStream bis = new BufferedInputStream(new FileInputStream(file), 8*1024*1024/2);
    long    total = 0;
    int i;
    while ((i = bis.read()) != -1)
    {
        byte    b = (byte)i;
        long    number = 0;
        while (b >= '0' && b <= '9')
        {
            number = number*10+b-'0';
            if ((i = bis.read()) == -1)
                break;
            b = (byte)i;
        }
        total += number;
    }

在文本文件中求和整数的最快方法

题