不敢相信?System.currentTimeMillis()存在性能问题
点击蓝色“程序猿DD”关注我
回复“资源”获取独家整理的学习资料!
推荐一个免费的写博神器:openwrite.cn。Markdown一次编写,轻松发布到CSDN、博客园、思否、掘金、简书等主流技术平台。
作者 | LittleMagic
System.currentTimeMillis()是极其常用的基础Java API,广泛地用来获取时间戳或测量代码执行时长等,在我们的印象中应该快如闪电。但实际上在并发调用或者特别频繁调用它的情况下(比如一个业务繁忙的接口,或者吞吐量大的需要取得时间戳的流式程序),其性能表现会令人大跌眼镜。
直接看代码
public class CurrentTimeMillisPerfDemo { private static final int COUNT = 100; public static void main(String[] args) throws Exception { long beginTime = System.nanoTime(); for (int i = 0; i < COUNT; i++) { System.currentTimeMillis(); } long elapsedTime = System.nanoTime() - beginTime; System.out.println("100 System.currentTimeMillis() serial calls: " + elapsedTime + " ns"); CountDownLatch startLatch = new CountDownLatch(1); CountDownLatch endLatch = new CountDownLatch(COUNT); for (int i = 0; i < COUNT; i++) { new Thread(() -> { try { startLatch.await(); System.currentTimeMillis(); } catch (InterruptedException e) { e.printStackTrace(); } finally { endLatch.countDown(); } }).start(); } beginTime = System.nanoTime(); startLatch.countDown(); endLatch.await(); elapsedTime = System.nanoTime() - beginTime; System.out.println("100 System.currentTimeMillis() parallel calls: " + elapsedTime + " ns"); }
}
执行结果如下图。
可见,并发调用System.currentTimeMillis()一百次,耗费的时间是单线程调用一百次的250倍。如果单线程的调用频次增加(比如达到每毫秒数次的地步),也会观察到类似的情况。实际上在极端情况下,System.currentTimeMillis()的耗时甚至会比创建一个简单的对象实例还要多,看官可以自行将上面线程中的语句换成new HashMap<>之类的试试看。
为什么会这样?
来到HotSpot源码的hotspot/src/os/linux/vm/os_linux.cpp文件中,有一个javaTimeMillis()方法,这就是System.currentTimeMillis()的native实现。
jlong os::javaTimeMillis() { timeval time; int status = gettimeofday(&time, NULL); assert(status != -1, "linux error"); return jlong(time.tv_sec) * 1000 + jlong(time.tv_usec / 1000);
}
挖源码就到此为止,因为已经有国外大佬深入到了汇编的级别来探究,详情可以参见《The Slow currentTimeMillis()》这篇文章。简单来讲就是:
调用gettimeofday()需要从用户态切换到内核态;
gettimeofday()的表现受Linux系统的计时器(时钟源)影响,在HPET计时器下性能尤其差;
系统只有一个全局时钟源,高并发或频繁访问会造成严重的争用。
HPET计时器性能较差的原因是会将所有对时间戳的请求串行执行。TSC计时器性能较好,因为有专用的寄存器来保存时间戳。缺点是可能不稳定,因为它是纯硬件的计时器,频率可变(与处理器的CLK信号有关)。关于HPET和TSC的细节可以参见https://en.wikipedia.org/wiki/HighPrecisionEventTimer与https://en.wikipedia.org/wiki/TimeStamp_Counter。
另外,可以用以下的命令查看和修改时钟源。
~ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
~ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
~ echo 'hpet' > /sys/devices/system/clocksource/clocksource0/current_clocksource
最常见的办法是用单个调度线程来按毫秒更新时间戳,相当于维护一个全局缓存。其他线程取时间戳时相当于从内存取,不会再造成时钟资源的争用,代价就是牺牲了一些精确度。具体代码如下。
public class CurrentTimeMillisClock { private volatile long now; private CurrentTimeMillisClock() { this.now = System.currentTimeMillis(); scheduleTick(); } private void scheduleTick() { new ScheduledThreadPoolExecutor(1, runnable -> { Thread thread = new Thread(runnable, "current-time-millis"); thread.setDaemon(true); return thread; }).scheduleAtFixedRate(() -> { now = System.currentTimeMillis(); }, 1, 1, TimeUnit.MILLISECONDS); } public long now() { return now; } public static CurrentTimeMillisClock getInstance() { return SingletonHolder.INSTANCE; } private static class SingletonHolder { private static final CurrentTimeMillisClock INSTANCE = new CurrentTimeMillisClock(); }
}
使用的时候,直接 CurrentTimeMillisClock.getInstance().now()
就可以了。
留言交流不过瘾
关注我,回复“加群”加入各种主题讨论群
点一点“阅读原文”小惊喜在等你
点击蓝色“程序猿DD”关注我
回复“资源”获取独家整理的学习资料!
推荐一个免费的写博神器:openwrite.cn。Markdown一次编写,轻松发布到CSDN、博客园、思否、掘金、简书等主流技术平台。
作者 | LittleMagic
System.currentTimeMillis()是极其常用的基础Java API,广泛地用来获取时间戳或测量代码执行时长等,在我们的印象中应该快如闪电。但实际上在并发调用或者特别频繁调用它的情况下(比如一个业务繁忙的接口,或者吞吐量大的需要取得时间戳的流式程序),其性能表现会令人大跌眼镜。
直接看代码
public class CurrentTimeMillisPerfDemo { private static final int COUNT = 100; public static void main(String[] args) throws Exception { long beginTime = System.nanoTime(); for (int i = 0; i < COUNT; i++) { System.currentTimeMillis(); } long elapsedTime = System.nanoTime() - beginTime; System.out.println("100 System.currentTimeMillis() serial calls: " + elapsedTime + " ns"); CountDownLatch startLatch = new CountDownLatch(1); CountDownLatch endLatch = new CountDownLatch(COUNT); for (int i = 0; i < COUNT; i++) { new Thread(() -> { try { startLatch.await(); System.currentTimeMillis(); } catch (InterruptedException e) { e.printStackTrace(); } finally { endLatch.countDown(); } }).start(); } beginTime = System.nanoTime(); startLatch.countDown(); endLatch.await(); elapsedTime = System.nanoTime() - beginTime; System.out.println("100 System.currentTimeMillis() parallel calls: " + elapsedTime + " ns"); }
}
执行结果如下图。
可见,并发调用System.currentTimeMillis()一百次,耗费的时间是单线程调用一百次的250倍。如果单线程的调用频次增加(比如达到每毫秒数次的地步),也会观察到类似的情况。实际上在极端情况下,System.currentTimeMillis()的耗时甚至会比创建一个简单的对象实例还要多,看官可以自行将上面线程中的语句换成new HashMap<>之类的试试看。
为什么会这样?
来到HotSpot源码的hotspot/src/os/linux/vm/os_linux.cpp文件中,有一个javaTimeMillis()方法,这就是System.currentTimeMillis()的native实现。
jlong os::javaTimeMillis() { timeval time; int status = gettimeofday(&time, NULL); assert(status != -1, "linux error"); return jlong(time.tv_sec) * 1000 + jlong(time.tv_usec / 1000);
}
挖源码就到此为止,因为已经有国外大佬深入到了汇编的级别来探究,详情可以参见《The Slow currentTimeMillis()》这篇文章。简单来讲就是:
调用gettimeofday()需要从用户态切换到内核态;
gettimeofday()的表现受Linux系统的计时器(时钟源)影响,在HPET计时器下性能尤其差;
系统只有一个全局时钟源,高并发或频繁访问会造成严重的争用。
HPET计时器性能较差的原因是会将所有对时间戳的请求串行执行。TSC计时器性能较好,因为有专用的寄存器来保存时间戳。缺点是可能不稳定,因为它是纯硬件的计时器,频率可变(与处理器的CLK信号有关)。关于HPET和TSC的细节可以参见https://en.wikipedia.org/wiki/HighPrecisionEventTimer与https://en.wikipedia.org/wiki/TimeStamp_Counter。
另外,可以用以下的命令查看和修改时钟源。
~ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
~ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
~ echo 'hpet' > /sys/devices/system/clocksource/clocksource0/current_clocksource
最常见的办法是用单个调度线程来按毫秒更新时间戳,相当于维护一个全局缓存。其他线程取时间戳时相当于从内存取,不会再造成时钟资源的争用,代价就是牺牲了一些精确度。具体代码如下。
public class CurrentTimeMillisClock { private volatile long now; private CurrentTimeMillisClock() { this.now = System.currentTimeMillis(); scheduleTick(); } private void scheduleTick() { new ScheduledThreadPoolExecutor(1, runnable -> { Thread thread = new Thread(runnable, "current-time-millis"); thread.setDaemon(true); return thread; }).scheduleAtFixedRate(() -> { now = System.currentTimeMillis(); }, 1, 1, TimeUnit.MILLISECONDS); } public long now() { return now; } public static CurrentTimeMillisClock getInstance() { return SingletonHolder.INSTANCE; } private static class SingletonHolder { private static final CurrentTimeMillisClock INSTANCE = new CurrentTimeMillisClock(); }
}
使用的时候,直接 CurrentTimeMillisClock.getInstance().now()
就可以了。
留言交流不过瘾
关注我,回复“加群”加入各种主题讨论群
点一点“阅读原文”小惊喜在等你
不敢相信?System.currentTimeMillis()存在性能问题相关推荐
- System.currentTimeMillis的性能真有如此不堪吗?
推荐大家关注一个公众号 点击上方 "编程技术圈"关注, 星标或置顶一起成长 后台回复"大礼包"有惊喜礼包! 每日英文 Two things always to ...
- java currenttimemillis 效率_高并发场景下System.currentTimeMillis()的性能问题的优化
前言 System.currentTimeMillis()的调用比new一个普通对象要耗时的多(具体耗时高出多少我也不知道,不过听说在100倍左右),然而该方法又是一个常用方法,有时不得不使用,比如生 ...
- System.currentTimeMillis的性能,真有如此不堪吗?
以下文章来源方志朋的博客,回复"666"获面试宝典 # 疑惑,System.currentTimeMillis真有性能问题? 最近我在研究一款中间件的源代码时,发现它获取当前时间不 ...
- System.currentTimeMillis的性能如何
一.背景 撸代码时发现System.currentTimeMillis的调用都被封装成了cache类型,代码如下: 那么System.currentTimeMillis真的有这么这么差吗,如果差的话又 ...
- System.currentTimeMillis()存在性能问题
System.currentTimeMillis()是极其常用的基础Java API,广泛地用来获取时间戳或测量代码执行时长等,在我们的印象中应该快如闪电.但实际上在并发调用或者特别频繁调用它的情况下 ...
- Java的System.currentTimeMillis()的性能问题
System.currentTimeMillis()是极其常用的基础Java API,广泛地用来获取时间戳或测量代码执行时长等,在我们的印象中应该快如闪电.但实际上在并发调用或者特别频繁调用它的情况下 ...
- System.currentTimeMillis()的性能问题以及解决方法
System.currentTimeMillis()是极其常用的基础Java API,广泛地用来获取时间戳或测量代码执行时长等,在我们的印象中应该快如闪电.但实际上在并发调用或者特别频繁调用它的情况下 ...
- 疑惑,System.currentTimeMillis真有性能问题?
点击关注公众号,Java干货及时送达 System.currentTimeMillis的性能真有如此不堪吗? 最近我在研究一款中间件的源代码时,发现它获取当前时间不是通过System.currentT ...
- Bullsh*t,System. currentTimeMillis大胆用起来,我说的!
以下文章来源方志朋的博客,回复"666"获面试宝典 # 疑惑,System.currentTimeMillis真有性能问题? 最近我在研究一款中间件的源代码时,发现它获取当前时间不 ...
最新文章
- 在存储过程中如何实现将ID列表字符串传入IN()
- C#中一些易混知识的比较
- java_spring_依赖注入(构造器)
- java 什么时候依赖注入_玩框架java依赖注入 – 何时使用单例
- 如何扩展分布式日志组件(Exceptionless)的日志通知?
- 写完程序 看 蜡笔小新 的有木有
- Windows编程—控制面板程序显示信息修改(程序图标、名称、链接等)
- 世界上第一位程序员,竟然是诗人拜伦的女儿?
- Chrome 开发工具 Workspace 使用
- 栈溢出脚本_漏洞练习之网络编程与堆栈溢出技术
- go插件 vscode 报错_MacOS中 VSCode 安装 GO 插件失败问题的快速解决方法
- linux文件名快速键入,linux修改文件名【使用模式】
- 华为背锅?微博大V质疑华为P30 Pro拍月亮造假 公司称误导观众已开除
- UVa 1347 旅行
- python网络爬虫系列教程——Python+PhantomJS +Selenium组合应用
- 思科CCNA考试命令集总结
- [frida] 01_食用指南(持续更新)
- MFC中CDC *PDC hDC 等等及Wnd的区别
- 商业研究(10):比呀比-海淘电商-海外正品直邮-高品质跨境购物平台
- 山东省淄博市谷歌高清卫星地图下载