性能文章>低开销获取时间戳>

低开销获取时间戳原创

8月前
184001

前言

在前面文章《Cobar SQL审计的设计与实现》中提了一句关于时间戳获取性能的问题

获取操作系统时间,在Java中直接调用 System.currentTimeMillis(); 就可以,但在Cobar中如果这么获取时间,就会导致性能损耗非常严重(怎么解决?去Cobar的github仓库上看看代码吧)。

这个话题展开具体说说,我们在Java中获取时间戳的方法是System.currentTimeMillis(),返回的是毫秒级的时间戳,查看源码,注释写的比较清楚,虽然该方法返回的是毫秒级的时间戳,但精度取决于操作系统,很多操作系统返回的精度是10毫秒。

    /**
     * Returns the current time in milliseconds.  Note that
     * while the unit of time of the return value is a millisecond,
     * the granularity of the value depends on the underlying
     * operating system and may be larger.  For example, many
     * operating systems measure time in units of tens of
     * milliseconds.
     *
     * <p> See the description of the class <code>Date</code> for
     * a discussion of slight discrepancies that may arise between
     * "computer time" and coordinated universal time (UTC).
     *
     * @return  the difference, measured in milliseconds, between
     *          the current time and midnight, January 1, 1970 UTC.
     * @see     java.util.Date
     */

    public static native long currentTimeMillis();

关于为什么System.currentTimeMillis()慢,有大佬写了文章详细地阐述了原因,建议仔细阅读,非常深入和详细,文章地址

http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html

总结起来原因是System.currentTimeMillis调用了gettimeofday()

  • 调用gettimeofday()需要从用户态切换到内核态;
  • gettimeofday()的表现受Linux系统的计时器(时钟源)影响,在HPET计时器下性能尤其差;
  • 系统只有一个全局时钟源,高并发或频繁访问会造成严重的争用。

我们测试一下System.currentTimeMillis()在不同线程下的性能,这里使用中间件常用的JHM来测试,测试1到128线程下获取1000万次时间戳需要的时间分别是多少,这里给出在我的电脑上的测试数据:

Benchmark                    Mode  Cnt  Score   Error  Units
TimeStampTest.test1Thread    avgt       0.271           s/op
TimeStampTest.test2Thread    avgt       0.272           s/op
TimeStampTest.test4Thread    avgt       0.278           s/op
TimeStampTest.test8Thread    avgt       0.375           s/op
TimeStampTest.test16Thread   avgt       0.737           s/op
TimeStampTest.test32Thread   avgt       1.474           s/op
TimeStampTest.test64Thread   avgt       2.907           s/op
TimeStampTest.test128Thread  avgt       5.732           s/op

可以看出在1-4线程下比较快,8线程之后就是线性增长了。

测试代码参考:

@State(Scope.Benchmark)
public class TimeStampTest {

    private static final int MAX = 10000000;

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(TimeStampTest.class.getSimpleName())
                .forks(1)
                .warmupIterations(1)
                .measurementIterations(1)
                .warmupTime(TimeValue.seconds(5))
                .measurementTime(TimeValue.seconds(5))
                .mode(Mode.AverageTime)
                .syncIterations(false)
                .build()
;

        new Runner(opt).run();
    }

    @Benchmark
    @Threads(1)
    public void test1Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(2)
    public void test2Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(4)
    public void test4Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(8)
    public void test8Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(16)
    public void test16Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(32)
    public void test32Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(64)
    public void test64Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    @Benchmark
    @Threads(128)
    public void test128Thread() {
        for (int i = 0; i < MAX; i++) {
            currentTimeMillis();
        }
    }

    private static long currentTimeMillis() {
        return System.currentTimeMillis();
    }
}

解法

最容易想到的方法是缓存时间戳,并使用一个独立的线程来更新它。这样获取就只是从内存中取一下,开销非常小,但缺点也很明显,更新的频率决定了时间戳的精度。

Cobar

Cobar获取和更新时间戳相关代码位于

https://github.com/alibaba/cobar/blob/master/server/src/main/server/com/alibaba/cobar/util/TimeUtil.java

/**
 * 弱精度的计时器,考虑性能不使用同步策略。
 * 
 * @author xianmao.hexm 2011-1-18 下午06:10:55
 */

public class TimeUtil {
    private static long CURRENT_TIME = System.currentTimeMillis();

    public static final long currentTimeMillis() {
        return CURRENT_TIME;
    }

    public static final void update() {
        CURRENT_TIME = System.currentTimeMillis();
    }

}

定时调度代码位于

https://github.com/alibaba/cobar/blob/master/server/src/main/server/com/alibaba/cobar/CobarServer.java

timer.schedule(updateTime(), 0L, TIME_UPDATE_PERIOD);
...
// 系统时间定时更新任务
private TimerTask updateTime() {
    return new TimerTask() {
        @Override
        public void run() {
            TimeUtil.update();
        }
    };
}

而Cobar中的更新间隔 TIME_UPDATE_PERIOD是20毫秒

Sentinel

Sentinel也用到了缓存时间戳,其代码位于

https://github.com/alibaba/Sentinel/blob/master/sentinel-core/src/main/java/com/alibaba/csp/sentinel/util/TimeUtil.java

public final class TimeUtil {

    private static volatile long currentTimeMillis;

    static {
        currentTimeMillis = System.currentTimeMillis();
        Thread daemon = new Thread(new Runnable() {
            @Override
            public void run() {
                while (true) {
                    currentTimeMillis = System.currentTimeMillis();
                    try {
                        TimeUnit.MILLISECONDS.sleep(1);
                    } catch (Throwable e) {

                    }
                }
            }
        });
        daemon.setDaemon(true);
        daemon.setName("sentinel-time-tick-thread");
        daemon.start();
    }

    public static long currentTimeMillis() {
        return currentTimeMillis;
    }
}

可以看到Sentinel实现的是每隔1毫秒缓存一次。

我们修改一下测试代码测试一下Sentinel的实现方式在1-128线程下的性能表现

Benchmark                    Mode  Cnt   Score   Error  Units
TimeStampTest.test1Thread    avgt       ≈ 10⁻⁴           s/op
TimeStampTest.test2Thread    avgt       ≈ 10⁻⁴           s/op
TimeStampTest.test4Thread    avgt       ≈ 10⁻⁴           s/op
TimeStampTest.test8Thread    avgt       ≈ 10⁻³           s/op
TimeStampTest.test16Thread   avgt        0.001           s/op
TimeStampTest.test32Thread   avgt        0.001           s/op
TimeStampTest.test64Thread   avgt        0.003           s/op
TimeStampTest.test128Thread  avgt        0.006           s/op

可以和直接使用System.currentTimeMillis对比,差距非常明显。

最后

虽然缓存时间戳性能能提升很多,但这也仅限于非常高的并发系统中,一般比较适用于高并发的中间件,如果一般的系统来做这个优化,效果并不明显。性能优化还是要抓住主要矛盾,解决瓶颈,切忌不可过渡优化。


欢迎关注我的公众号“捉虫大师”

 

请先登录,感受更多精彩内容
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

JVM 源码分析之一个 Java 进程究竟能创建多少线程
概述虽然这篇文章的标题打着JVM源码分析的旗号,不过本文不仅仅从 JVM 源码角度来分析,更多的来自于 Linux Kernel 的源码分析,今天要说的是 JVM 里比较常见的一个问题。这个问题可能有
线程池运用不当的一次线上事故
在高并发、异步化等场景,线程池的运用可以说无处不在。线程池从本质上来讲,即通过空间换取时间,因为线程的创建和销毁都是要消耗资源和时间的,对于大量使用线程的场景,使用池化管理可以延迟线程的销毁,大大提高
YGC问题排查,又让我涨姿势了!
在高并发下,Java程序的GC问题属于很典型的一类问题,带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」,由于GC期间都存在Stop The World问题,因此很容易导致服务
【活动结果公布:兑奖见置顶评论】每日一签到,解锁你的PerfMa壕礼
叮......Perfma达人福利发车啦!社区每日签到解锁活动上线啦~除了每日签到必得积分奖励外,还为大家增加了壕礼相赠、解锁Perfma终极大奖等环节奖励 ~来Perfma社区留下你的签到足迹,告诉
使用Top_X插件排查内存过载问题
Top命令是Linux 系统下常用的监控工具,用于实时获取进程级别的 CPU 或内存使用情况。XPocket中的Top_X为Linux Top的增强版,可以显示CPU占用率/负载,CPU及内存进程使用
记一次Synchronized关键字使用不合理,导致的多线程下线程阻塞问题排查
在为客户进行性能诊断调优时,碰到了一个Synchronized关键字使用不合理导致多线程下线程阻塞的情况。用文字记录下了问题的整个发现-排查-分析-优化过程,排查过程中使用了我司商业化产品——XLan
记一次类加载失败导致线程阻塞问题排查
作为PerfMa解决方案管理部门的技术专家,我在工作遇见过很多各种问题导致的性能问题,并参与了为客户的系统进行性能诊断调优的全过程。这一次碰到了一个类加载失败导致的性能问题。用文字记录下了问题的整个发
一次大量 JVM Native 内存泄露的排查分析(64M 问题)
我们有一个线上的项目,刚启动完就占用了使用 top 命令查看 RES 占用了超过 1.5G,这明显不合理,于是进行了一些分析找到了根本的原因,下面是完整的分析过程,希望对你有所帮助。会涉及到下面这些内容Linux 经典的 64M 内存问题堆内存分析、Native 内存分析的基本套路