一、前言

System.currentTimeMillis()的调用比new一个普通对象要耗时的多(具体耗时高出多少我也不知道,不过听说在100倍左右),然而该方法又是一个常用方法,

有时不得不使用,比如生成wokerId、打印日志什么的,在高并发情形下肯定存在性能问题的,但怎么做才好呢? System.currentTimeMillis()之所以慢是因为

去跟系统打了一次交道。那什么快?内存!如果该方法从内存直接取数,那不就美滋滋了。

二、代码实现

public class SystemClock {

    private final long period;

    private final AtomicLong now;

    private SystemClock(long period) {
this.period = period;
this.now = new AtomicLong(System.currentTimeMillis());
scheduleClockUpdating();
} private static SystemClock instance() {
return InstanceHolder.INSTANCE;
} public static long now() {
return instance().currentTimeMillis();
} public static String nowDate() {
return new Timestamp(instance().currentTimeMillis()).toString();
} private void scheduleClockUpdating() { ScheduledThreadPoolExecutor scheduler = new ScheduledThreadPoolExecutor(1, new ThreadFactory() { @Override
public Thread newThread(Runnable r) {
Thread thread = new Thread(r, "System Clock");
thread.setDaemon(true);
return thread;
}
}); scheduler.scheduleAtFixedRate(new Runnable() { @Override
public void run() {
now.set(System.currentTimeMillis());
}
}, period, period, TimeUnit.MILLISECONDS);
} private long currentTimeMillis() {
return now.get();
} private static class InstanceHolder {
public static final SystemClock INSTANCE = new SystemClock(1);
}
}

用的时候直接调用SystemClock.now();就ok了。

测试

写了一个简单的测试代码:

    public static void main(String[] args) {
long start = System.currentTimeMillis();
for (long i = 0; i < Integer.MAX_VALUE; i++) {
SystemClock.now();
}
long end = System.currentTimeMillis();
System.out.println("SystemClock Time:" + (end - start) + "毫秒");
long start2 = System.currentTimeMillis();
for (long i = 0; i < Integer.MAX_VALUE; i++) {
System.currentTimeMillis();
}
long end2 = System.currentTimeMillis();
System.out.println("currentTimeMillis Time:" + (end2 - start2) + "毫秒");
}

输出结果是:
  SystemClock Time:1787毫秒
  currentTimeMillis Time:33851毫秒
  看着结果效率提升还是挺明显的。

  所有的进步都是不稳定, 一个问题解决了又不得不面对一个新的问题。
 
转载自:https://www.cnblogs.com/nyvi/p/8837012.html

高并发场景下System.currentTimeMillis()的性能优化的更多相关文章

  1. 高并发场景下System.currentTimeMillis()的性能问题的优化 以及SnowFlakeIdWorker高性能ID生成器

    package xxx; import java.sql.Timestamp; import java.util.concurrent.*; import java.util.concurrent.a ...

  2. 高并发场景下System.currentTimeMillis()的性能问题的优化

    高并发场景下System.currentTimeMillis()的性能问题的优化 package cn.ucaner.alpaca.common.util.key; import java.sql.T ...

  3. HttpClient在高并发场景下的优化实战

    在项目中使用HttpClient可能是很普遍,尤其在当下微服务大火形势下,如果服务之间是http调用就少不了跟http客户端找交道.由于项目用户规模不同以及应用场景不同,很多时候可能不需要特别处理也. ...

  4. Qunar机票技术部就有一个全年很关键的一个指标:搜索缓存命中率,当时已经做到了>99.7%。再往后,每提高0.1%,优化难度成指数级增长了。哪怕是千分之一,也直接影响用户体验,影响每天上万张机票的销售额。 在高并发场景下,提供了保证线程安全的对象、方法。比如经典的ConcurrentHashMap,它比起HashMap,有更小粒度的锁,并发读写性能更好。线程安全的StringBuilder取代S

    Qunar机票技术部就有一个全年很关键的一个指标:搜索缓存命中率,当时已经做到了>99.7%.再往后,每提高0.1%,优化难度成指数级增长了.哪怕是千分之一,也直接影响用户体验,影响每天上万张机 ...

  5. C++高并发场景下读多写少的解决方案

    C++高并发场景下读多写少的解决方案 概述 一谈到高并发的解决方案,往往能想到模块水平拆分.数据库读写分离.分库分表,加缓存.加mq等,这些都是从系统架构上解决.单模块作为系统的组成单元,其性能好坏也 ...

  6. C++高并发场景下读多写少的优化方案

    概述 一谈到高并发的优化方案,往往能想到模块水平拆分.数据库读写分离.分库分表,加缓存.加mq等,这些都是从系统架构上解决.单模块作为系统的组成单元,其性能好坏也能很大的影响整体性能,本文从单模块下读 ...

  7. 【转】记录PHP、MySQL在高并发场景下产生的一次事故

    看了一篇网友日志,感觉工作中值得借鉴,原文如下: 事故描述 在一次项目中,上线了一新功能之后,陆陆续续的有客服向我们反应,有用户的个别道具数量高达42亿,但是当时一直没有到证据表示这是,确实存在,并且 ...

  8. MySQL在大数据、高并发场景下的SQL语句优化和"最佳实践"

    本文主要针对中小型应用或网站,重点探讨日常程序开发中SQL语句的优化问题,所谓“大数据”.“高并发”仅针对中小型应用而言,专业的数据库运维大神请无视.以下实践为个人在实际开发工作中,针对相对“大数据” ...

  9. 高并发场景下JVM调优实践之路

    一.背景 2021年2月,收到反馈,视频APP某核心接口高峰期响应慢,影响用户体验. 通过监控发现,接口响应慢主要是P99耗时高引起的,怀疑与该服务的GC有关,该服务典型的一个实例GC表现如下图: 可 ...

随机推荐

  1. and和or运算

    and和or的运算,从前向后按顺序计算,当True结果遇到or就停止,返回True:当False结果遇到and就停止,返回False:False遇到or,继续走:True遇到and,继续走. > ...

  2. CF1029C Maximal Intersection

    https://www.luogu.org/problem/show?pid=CF1029C #include<bits/stdc++.h> using namespace std ; # ...

  3. 下载linaro android 4.4.2 for panda4460

    $ export MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git$ export MANIFEST_BRANCH=li ...

  4. kettle 增量同步

    http://www.cnblogs.com/inuyasha1027/p/Kettle_update_timestamp.html https://ask.hellobi.com/blog/yugu ...

  5. poj:1985:Cow Marathon(求树的直径)

    Cow Marathon Time Limit: 2000MS   Memory Limit: 30000K Total Submissions: 5496   Accepted: 2685 Case ...

  6. python socket相关

    套接字的工作流程(基于TCP和 UDP两个协议) TCP和UDP对比 TCP(Transmission Control Protocol)可靠的.面向连接的协议(eg:打电话).传输效率低全双工通信( ...

  7. MongoDB学习-->Gridfs分布式存储&DBRef关联查询

    mongodb自带的一个分布式文件系统 fs.files _id filename md5 size uploaddate contenttype metadata {"user_id&qu ...

  8. 零基础学 JavaScript 全彩版 明日科技 编著

    第1篇 基础知识 第1章 JavaScript简介 1.1 JavaScript简述 1.2 WebStorm的下载与安装 1.3 JavaScript在HTML中的使用 1.3.1 在页面中直接嵌入 ...

  9. 缓存淘汰算法之LRU实现

    Java中最简单的LRU算法实现,就是利用 LinkedHashMap,覆写其中的removeEldestEntry(Map.Entry)方法即可 如果你去看LinkedHashMap的源码可知,LR ...

  10. 使用 Rails Webpacker 安裝 Foundation 6

    動機 由於 foundation-rails 6.4.1 版本有個 Issue 目前還沒合併.加上 Rails 已經支援了 webpack 2.x.這篇文章純粹紀錄另外一種做法. 準備 開始使用之前需 ...