java取余操作的坑

本文通过一个简单的比赛实例揭示了在循环中使用%运算可能导致的性能问题。作者指出,相比于加法操作,%运算在大量重复执行时显著增加了程序运行时间,提醒开发者在注重效率的场景下谨慎使用此类运算符。此外,文中还提及了&运算同样可能带来额外的时间消耗。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

%操作慎用!!!
本人比赛时遇到的坑,简单的题但是时间超了

public static void main(String[] args) {
    //System.currentTimeMillis() 
    //从1970年01月01日00时00分00秒000毫秒到此刻的毫秒数返回类型是long类型
    long time = System.currentTimeMillis();
    int a = Integer.MAX_VALUE;
    for (int i = 1; i < 100000; i ++) {
        for (int j = 1; j < 100000; j ++) {
            a = a % 2;
        }

    }
    long itime = System.currentTimeMillis();
    long time2 = System.currentTimeMillis();
    for (int i = 0; i < 100000 ; i ++) {
        for (int j = 1; j < 100000; j ++) {
            a = a + 1;
        }
    }
    long itime2 = System.currentTimeMillis();
    System.out.println(time);
    System.out.println(itime);
    System.out.println(time2);
    System.out.println(itime2);
    System.out.println(a);
}

输出结果如下:
time : 1636903381528
itime :1636903392879
time: 21636903392879
itime :21636903392879
a : 1409965409

可以看到运用了%运算,耗时慢了10秒

坑!!!

打比赛的小伙伴一定要慎用%运算

| 和 & 也有一定的耗时

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

海边的宇航员

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值