棋盘放麦子问题,一共64格

我这个用2的0次方到63次方想加,但答案输出到和问题的答案不一样,这个问题的答案是18446744073709551614但我这个有点太大了,我又想不出来我代码哪里有问题

img

img

因为题目的结果已经超过long表示的最大值了,long最大值:9,223,372,036,854,775,807
使用BigInteger存储结果便可,代码修改如下:

import java.math.BigInteger;

public class TwoPowerSum {
    public static void main(String[] args) {
        BigInteger sum = BigInteger.ZERO;
        for (int i = 0; i <= 63; i++) {
            BigInteger base = BigInteger.valueOf(2);
            BigInteger pow = base.pow(i);
            sum = sum.add(pow);
        }
        System.out.println(sum);
    }
}

这个要用 BigInteger 类 double long都不够。

因为数据的长度超过了lang范围,不用强转为lang

img

参考一下:

public class ChessBoard {
    public static void main(String[] args) {
        long total = 0; // 麦子总数
        long grains = 1; // 每个格子应该放的麦子数,初始为1
        int squares = 64; // 棋盘格数,即需要计算的次数

        for (int i = 1; i <= squares; i++) {
            total += grains; // 累加当前格子应该放的麦子数
            grains *= 2; // 计算下一个格子应该放的麦子数,即前一个格子麦子数的2倍
        }

        System.out.println("需要的麦子总数为:" + total);
    }
}


img

  • 这有个类似的问题, 你可以参考下: https://ask.csdn.net/questions/740405
  • 这篇博客你也可以参考下:创建数据库时,出现错误,提示消息 5133 对文件的目录查找失败,消息 1802,无法创建列出的某些文件名
  • 除此之外, 这篇博客: 记录自己的成长0331-0229中的 6、碰到的问题介绍一下? 部分也许能够解决你的问题, 你可以仔细阅读以下内容或跳转源博客中阅读:
  • 有一个业务模块,资源占用率在逐步升高。设的是一个 hpa 自动扩容缩操作,当它扩容到顶点之后,它就会报警。根据经验来判断,它这个因为访容量增加,导致它这个业务模块就是资源使用率升高。做了扩容操作,两个小时左右再一次报警。然后又进行了一次扩容操作。然后第三次报警的时候,我才发现可能是不太正常。然后之后我是查询了一个访问量日志访问量,内存使用的趋势图。然后对你这个占用那个内存的这个 POD 来进行一个监控,发现那个有一个报警,就是那个 oome 然后最后经过排查确定是那个内存溢出的一个问题。然后因为当时比较晚,也就是给那几个开发人员打电话,有的也打不通。最后找到一个开发人员,我是跟他沟通是想让他如果能尽快定位问题,我这边也如果他这边说把个代码相关操作给我发过来,我这边可以进行一个更新,但是他说这边是定位不到问题,最后没有办法,进行了一个版本回滚操作。回滚之后其实我们这个业务模块就恢复回复到之前的样子了。然后最后之后这个事情是之后解决的。

    因为这个问题是经常比较常遇到的,我们这边访问量上涨,然后没有跑量上涨进行扩容。有事先预案,另一个根据经验判断,当时是一个错误的操作,完全因为事情也比较多,当时错误的操作进行扩容,导致这个问题处理没有及时处理掉。

    预案。就是我们每一次放假之前都是会首先一个对我们这个之前的历史记录进行一个分析,然后分析哪个集群还行,需要的资源会更多一些,然后资源调优。另一个如果说我这个集群如果挂掉了,因为访问量继争挂掉了,我应该怎样去切流,重启这些操作,怎样去保持这个服务可用性。

    实际演练这个会的。

    你这个步骤不是很完整,就是一个大致的方案。

    主要看我们这边工作经验了吧。这个其实这个因为主要主要是什么呢?因为我们这边其实资源是充足的,所以我们虽然做预案,但是可能说平时出现那种紧急故障,大型大规模的故障比较少,所以说对方面确实是有一些薄弱。