System.currentTimeMillis () vs. 새로운 Date () vs. Calendar.getInstance (). getTime ()


239

Java에서 사용시 성능 및 자원에 미치는 영향

System.currentTimeMillis() 

vs.

new Date() 

vs.

Calendar.getInstance().getTime()

내가 이해하는 System.currentTimeMillis()것이 가장 효율적입니다. 그러나 대부분의 응용 프로그램에서이 긴 값은 날짜 또는 이와 유사한 객체로 변환하여 사람에게 의미있는 작업을 수행해야합니다.

답변:


242

System.currentTimeMillis()그것은 심지어 객체를 만들지 않기 때문에 가장 효율적입니다 . 그러나 new Date()실제로는 오랫동안 얇은 래퍼이기 때문에 그리 멀지 않습니다. Calendar반면에, 날짜와 시간에 고유 한 상당히 복잡한 모든 기이함 (윤년, 일광 절약 시간, 시간대 등)을 다루어야하기 때문에 상대적으로 느리고 매우 복잡합니다.

일반적으로 Date응용 프로그램 내에서 긴 타임 스탬프 또는 개체 만 처리 하고 Calendar실제로 날짜 / 시간 계산을 수행해야하거나 사용자에게 표시 할 날짜 형식을 지정하는 경우 에만 사용 하는 것이 좋습니다. 이 작업을 많이 수행해야하는 경우 Joda Time을 사용 하는 것이 더 깔끔한 인터페이스와 더 나은 성능을위한 좋은 아이디어 일 것입니다.


2
타임 스탬프와 currentMillis의 차이점은 무엇입니까?
pinkpanther

1
@pinkpanther : "timestamp"는 일반적으로 "epoch start"이후 초 또는 밀리 초로 해석 될 때 특정 시점을 나타내는 정수 / 길이를 나타내는 데 사용됩니다. 즉, currentTimeMillis ()는 타임 스탬프를 반환합니다.
Michael Borgwardt

43

JDK를 살펴보면 가장 안쪽 생성자 Calendar.getInstance()는 다음과 같습니다.

public GregorianCalendar(TimeZone zone, Locale aLocale) {
    super(zone, aLocale);
    gdate = (BaseCalendar.Date) gcal.newCalendarDate(zone);
    setTimeInMillis(System.currentTimeMillis());
}

이미 제안한 내용을 자동으로 수행합니다. 날짜의 기본 생성자는 다음을 보유합니다.

public Date() {
    this(System.currentTimeMillis());
}

따라서 달력 / 날짜 개체를 만들기 전에 계산을하지 않는 한 시스템 시간을 구체적으로 알 필요는 없습니다. 또한 날짜 계산을 많이하는 것이 목적이라면 Java 자체 달력 / 날짜 클래스를 대체하기 위해 joda-time 을 권장 해야합니다.


22

날짜를 사용하는 경우 jodatime, http://joda-time.sourceforge.net/ 을 사용하는 것이 좋습니다 . 사용 System.currentTimeMillis()필드에 있는 아주 나쁜 생각처럼 날짜 소리 당신은 쓸모없는 코드를 많이하게 될 겁니다 때문이다.

날짜와 달력 모두 심각하게 지겨워졌으며 달력은 그들 모두의 최악의 수행자입니다.

System.currentTimeMillis()실제로 밀리 초로 작동 할 때 사용하는 것이 좋습니다.

 long start = System.currentTimeMillis();
    .... do something ...
 long elapsed = System.currentTimeMillis() -start;

28
나는 당신의 예를 정확하게 당신이해야하는 것 중 하나이기 때문에이에 대해 언급하고 싶어 하지 대한에 System.currentTimeMillis ()를 사용; 단조로운 클럭 소스가 아니므로 경과 시간을 안정적으로 계산할 수 없습니다. 타이밍 코드를 실행하는 동안 시스템 시계가 변경되면 이상한 (예 : 음수) 결과가 나타납니다. 대신 사용 System.nanoTime ()에서 단조 경우 기본 시스템 지지부 같은 클럭 소스 (참조 bugs.java.com/bugdatabase/view_bug.do?bug_id=6458294 )
REM

System.currentTimeMillis 자체는 표준 시간대의 영향을받지 않습니다. 시스템 시간을 변경하면 System.currentTimeMillis와 같은 방식으로 System.nanotime에 영향을줍니다.
Viktor

12

나는에 의해 반환 된 값을 사용하여 선호 System.currentTimeMillis()계산의 모든 종류를 만 사용 Calendar또는 Date정말 인간이 읽을 수있는 값을 표시해야하는 경우. 이렇게하면 일광 절약 시간제 버그의 99 %가 방지됩니다. :)


12

내 컴퓨터에서 확인하려고했습니다. 내 결과 :

Calendar.getInstance (). getTime () (* 1000000 회) = 402ms
새 날짜 () .getTime (); (* 1000000 배) = 18ms
System.currentTimeMillis () (* 1000000 배) = 16ms

GC를 잊지 마십시오 (또는를 사용하는 Calendar.getInstance()경우 new Date())


1
많은 스레드가 다른 처리와 같은에서 호출하는 경우 궁금 차이가있을 것입니다 경우
tgkprog

7

응용 프로그램에 따라 System.nanoTime()대신 사용하는 것이 좋습니다.


왜 그의 질문은 자원과 성능에 관한 것이 었는가, nanoTime ()은 더 많은 자원을 사용합니다
WolfmanDragon

다른 사람이 제안하지 않은 옵션이기 때문에 언급했습니다. 포스터가 플랫폼을 지정하지 않았습니다. SDN 버그 6876279는 일부 JDK 버전에서 currentTimeMillis () 및 nanoTime ()이 거의 동일하다고 제안합니다. 포스터는 또한 원래의 목록이 부적절 할 수있는 정확성 요구를 명시하지 않았습니다.
MykennaC

4
이것이 늦어도, 질문의 모든 예는 예를 들어 몇시인지에 대한 절대적인 개념을 가지고 있습니다. 유닉스 시대가 시작된 이래 1,348,770,313,071 밀리 초. nanoTime반환 되는 시간 은 상대적으로 (일반적으로 프로그램 시작과 관련이 있으며) 날짜로 바꾸려고하면 말도 안됩니다.
모래 언덕

네, 그러나 프로그램 시작시 정적 코드에 currentTimeilli와 nano를 저장 한 다음 오프셋으로 사용하여 이중 var = currentTimeStart-nanoTimeStart + nanoTimeNow
tgkprog

3

나는 이것을 시도했다 :

        long now = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            new Date().getTime();
        }
        long result = System.currentTimeMillis() - now;

        System.out.println("Date(): " + result);

        now = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            System.currentTimeMillis();
        }
        result = System.currentTimeMillis() - now;

        System.out.println("currentTimeMillis(): " + result);

결과는 다음과 같습니다.

날짜 () : 199

currentTimeMillis () : 3


4
이것은 작은 벤치 마크이며 결과를 신뢰할 수 있도록주의해야합니다. stackoverflow.com/questions/504103/…을 살펴보십시오 .
Axel

1
이 벤치 마크는 그다지 중요하지 않거나 더 나은 것은 Java 운영 체제가 중요하다는 것을 보여줍니다. 동일한 벤치 마크를 수십 번 반복하여 실행했습니다 (루프에서 "현재"및 "결과"의 초기화를 이동). 각 실행마다 귀여운 차이가있었습니다. Date () : 322 to 330; currentTimeMillis () : 319 ~ 322. 다른 실행에서 Date () : 312 ~ 318; currentTimeMillis () : 324 ~ 335. 따라서 IMHO는 실제 경우 (날짜의 소스도 확인)와 동일합니다. JFYI, 우분투에서 Java7을 사용했습니다.
Sampisa

0

System.currentTimeMillis() 메서드 호출이 하나 뿐이고 가비지 수집기가 필요하지 않기 때문에 분명히 가장 빠릅니다.


14
귀하의 답변은 이전에 승인 된 답변의 일부에 불과하므로 아무런 가치가 없습니다. 이 방법으로 답변하지 마십시오. 특히 이미 존재하는 품질 답변이있는 매우 오래된 질문 인 것은 아닙니다.
Nicklas Gnejs Eriksson

1
둘째, 어쨌든 Eden 공간의 단기 객체에는 가비지 수집기가 필요하지 않습니다.
Niels Bech Nielsen
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.