딥블루딥블루

좀 더 편한 터미널 환경을 만들기 위해 MacPorts로 coreutils 설치 후 ln을 다음과 같이 변경시켰다.

(coreutils는 /opt/local/bin 에 설치되며 명령어에 'g' prefix가 붙는다.)

그후 ,VirtualBox 새버전을 내려 받아 설치했다.

그런데, 설치가 되지 않고 이런 에러만 내뱉는다. 지웠다 재설치도 해보고, 리부팅도 해보고 그래도 안된다.

(스크린샷을 안떠놔서 웹에서 영문버전 스크린샷을..)
웹 서핑을 해도 별다른 해결책이 안보인다.

혹시나 시스템 로그를 뒤져보면 뭔가 답이 나올것 같아 몇개의 파일을 살펴보던 중

/var/log/install.log 에서 VirtualBox 관련 메시지를 찾았다.

아.. 이게 뭔가.. >.<

coreutils 설치 후 ln을 /opt/local/bin/ln으로 바꿔놓은게 원인이었다. ㅜㅜ

coreutils 설치 명령은 다음과 같다.

여기서 +with_default_names 옵션은 mac의 명령들을 대체하도록 하는 옵션인데, 검색해보니 수많은 문제를 일으켜 옵션이 안먹도록 제거되었다고 한다.

여러 프로그램들이 mac용 명령어의 옵션을 사용하므로, 옵션이 다른 coreutils들을 호출했다가는 에러가 나기 때문일 것으로 추측된다.

(해결)

따라서, 다음과 같이 설정을 바꾸고, 원래 mac 명령어들을 원복시켜줬다.

/bin/ln, /bin/ls는 원복해서 VirtualBox install에는 문제없게 하고, 터미널 환경은 개선하기 위해 

PATH에 /opt/local/bin이 젤 앞에 오도록 하고, 자주 사용하는 ln과 ls만 rename했다.

그리고, VirtualBox 재설치..

짜잔~ 성공!

맥북프로에서 맥북에어로 갈아타면서, 다음엔 시행착오 없이 잘 셋팅할 수 있게 한번 정리해본다.

다음 순서로 설치하니 우왕좌왕 않고 잘 되었다.

(1) 키보드 / 마우스 설정

<한영 변환 shift+space키로 변경>

http://macnews.tistory.com/297

http://macnews.tistory.com/178

딜레이 없이 빠르게 OS X에서 한글-영어 입력기 전환하기.pdf

<USB 키보드 사용시 home/end 키 등 다시 설정해주기>

DefaultKeyBinding.dict

~/Library/KeyBindings/DefaultKeyBinding.Dict 에 위치시켜준다.

상세는 파일 내용 참조.
Karabiner-Elements 필요 없음!

<USB 키보드 Control, Option, Command 키 변경>

시스템 환경설정 > 키보드 > 키보드 > 보조키... > 키보드 선택 후 원하는 키로 변경

<휠 마우스 스크롤 방향 변경>

맥에서 일반 usb 마우스 휠 스크롤을 해보면 뭔가 좀 이상함을 느끼는데, 트랙패드 방향으로 맞춰져 있어서 Windows PC와 반대 방향으로 움직인다.
ScrollReverser를 설치하고 '수직 반전', '마우스 반전'만 켜준다. 트랙패드는 원래대로 두는 것이 자연스럽다.
- https://pilotmoon.com/scrollreverser/

(2) Xcode 설치

    - 개발환경을 만들기 위해서는 기본으로 설치해야 한다.

    - 아래의 MacPorts를 설치하기 위해서도 필요하다.

    - Xcode가 설치되면, Preference > Downloads 탭에서 "Command Line Tools"를 설치한다.

(3) MapPorts 설치 --> 아예 설치하지 말고 homebrew를 사용하자.

    - 좀 더 나은 작업환경을 위해서 2% 부족한 터미널 명령들을 업그레이드 하기 위해서 필수이다.

    - MacPorts는 기타 무료 / 오픈 소스 소프트웨어 의 도입을 단순화하기위한 자유 / 오픈 소스 소프트웨어 프로젝트이다. (위키피디아)

    - http://www.macports.org/install.php 에서 자신의 Mac OS버전에 맞는 링크를 눌러 다운로드 받아 설치한다.

(4) 좀 더 나은 터미널 환경 (macport는 사용말자. homebrew (4)-1 참고)

   - 맥의 기본 명령어들, 대표적으로 'ls'는 기능이 미약하고, 좀 후지다. brew를 이용하여 개선해보자.

   - Xcode의 'Command Line Tools'가 설치되어 있지 않다면 설치해야 한다. make가 필요하기 때문.

   - homebrew 설치 (이제 모든 설치물들은 /usr/local 아래에 설치된다.)

     http://brew.sh/

   - bash, coreutils, binutils, gnu-utils, subversion 등을 설치

     https://www.topbug.net/blog/2013/04/14/install-and-use-gnu-command-line-tools-in-mac-os-x/

(5) 디스크 파티션 분할하기

(※ 기기 변경을 몇 번 거치면서 느낀건.. 안하는게 낫더라. (1) Xcode 업데이트나 Mac OS 업데이트 시 master 파티션 공간 부족으로 이리저리 앱을 옮기거나 정리한 적이 잦았다 (2) 데이터만 남기고 mac을 재설치하거나 하는 경우는 없었다. 해서.. 굳이 이걸 할필요는 없는 듯..)

    - 이 작업은 제일 먼저해도 되고, 좀 더 수월한 작업환경을 갖춰놓고 해도 좋다.

    - 250GB 디스크를 70GB primary, 180GB data 파티션으로 분할했다. 혹시나 OS재설치를 대비해 home 디렉토리와 모든 데이터는 data 파티션으로 가도록 설정할 것이다. (DataHD가 data 파티션이다. 백업해뒀던 파일을 몽땅 복사했더니 용량이 얼마 안남았네 ;;;)

(6) home 디렉토리 변경 (파티션 분할 한 경우)

 방법은 대강 3가지 정도가 있다.

 (방법1) /Users 디렉토리를 data 파티션의 적절한 디렉토리로 마운트 하는 방법. /etc/fstab 등을 건드려야하고 할게 많다.

 (방법2) 사용자 설정 > 고급 설정 에서  사용자 home 디렉토리를 data 파티션의 디렉토리로 지정하는 방법.

 (방법3) /Users 디렉토리의 사용자 계정을 data 파티션의 디렉토리로 symbolic link를 걸어주는 방법.

 다음은 (방법3)에 대한 절차이다. (방법1,2는 구글링으로 찾으면 많은 문서가 있다.)

    - 분리한 data 파티션으로 홈 디렉토리를 옮겨준다.

    - 계정 이름을 "deepblue"라고 했을 경우, 다음과 같이 symbolic link를 설정한다.

    - 기존 home은 deepblue.ori로 변경하고, /Volumes/DataHD/home/deepblue 를 home으로 link를 걸어준다.

    - 당연한 얘기지만, /Volumes/DataHD/home/deepblue 는 미리 생성되어 있어야 한다. 홈 디렉토리의 모든 내용을 복사해주자. 숨긴 파일까지 포함해서 옮기는건 당연~

    - $ cd /Users

    - $ sudo mv deepblue deepblue.ori

    - $ sudo ln -s /Volumes/DataHD/home/deepblue deepblue

    - symbolic link를 걸어준 후 컴퓨터를 재시작한다. (로그아웃했다가 다시 로그인해도 된다.)

    - 설정들을 확인해보고 크게 문제 없으면, deepblue.ori는 삭제한다.

    - ※ 맥북프로에서 맥북에어로 갈아타면서 기존 사용하던 홈을 그대로 link시켰더니, 대부분의 설정이 그대로 적용되었다. 하지만, 일부 설정은 다시 맞춰줘야 했다. 별 설정없이 기존 환경 그대로 사용할 수 있어서 편하네. ㅎㅎ

(7) 기타 프로그램들

    - istat menus

    - Dropbox

    - Evernote

    - Chrome

    - PhotoScape X: 이미지 뷰어.

    - VirtualBox

    - VisualVm

    - Wunderlist

    - ...

SynchronizedCollections(동기화된 컬렉션)과 ConcurrentCollections(병렬 컬렉션)

동기화된 컬렉션 클래스는 컬렉션의 내부 변수에 접근하는 통로를 일련화해서 스레드 안전성을 확보했다. 하지만 이렇게 만들다 보니 여러 스레드가 한꺼번에 동기화된 컬렉션을 사용하려고 하면 동시 사용성은 상당 부분 손해를 볼 수 밖에 없다. 하지만 병렬 컬렉션은 여러 스레드에서 동시에 사용할 수 있도록 설계되었다.

ConcurrentMap에는 put-if-absent, replace, condition-remove 등을 정의하고 있다.

기존에 사용하던 동기화 컬렉션 클래스를 병렬 컬렉션으로 교체하는 것만으로도 별다른 위험 요소 없이 전체적인 성능을 상당히 끌어 올릴 수 있다.

<에이콘 - 자바 병렬 프로그래밍(p.137) 발췌>

동기화되지 않은(unsynchronized) 컬렉션

- List: ArrayList, LinkedList

- Map: HashMap

- Set: HashSet

- SortedMap: TreeMap

- SortedSet: TreeSet

- Since JDK 1.2

- 문제점: Thread Safe하지 않다.

동기화된(synchronized) 컬렉션

- Vector, Hashtable, Collections.synchronizedXXX()로 생성된 컬렉션들

- Since JDK 1.2

- 문제점: Thread Safe하나, 두개 이상의 연산을 묶어서 처리해야 할 때 외부에서 동기화 처리를 해줘야 한다. (Iteration, put-if-absent, replace, condition-remove 등)

병렬(concurrent) 컬렉션

- List: CopyOnWriteArrayList

- Map: ConcurrentMap, ConcurrentHashMap

- Set: CopyOnWriteArraySet

- SortedMap: ConcurrentSkipListMap (Since Java 6)

- SortedSet: ConcurrentSkipListSet (Since Java 6)

- Queue 계열:ConcurrentLinkedQueue

- Since Java 5

- 특이사항: Concurrent(병렬/동시성)이란 단어에서 알 수 있듯이 Synchronized 컬렉션과 달리 여러 스레드가 동시에 컬렉션에 접근할 수 있다. ConcurrentHashMap의 경우, lock striping 이라 부르는 세밀한 동기화 기법을 사용하기 때문에 가능하다. 구현 소스를 보면 16개의 락 객체를 배열로 두고 전체 Hash 범위를 1/16로 나누어 락을 담당한다. 최대 16개의 스레드가 경쟁없이 동시에 맵 데이터를 사용할 수 있게 한다. (p.350)

반대로 단점도 있는데, clear()와 같이 전체 데이터를 독점적으로 사용해야할 경우, 단일 락을 사용할 때보다 동기화 시키기도 어렵고 자원도 많이 소모하게 된다. 또한, size(), isEmpty()같은 연산이 최신값을 반환하지 못할 수도 있다. 하지만 내부 상태를 정확하게 알려주지 못한다는 단점이 그다지 문제되는 경우는 거의 없다.

※ Queue, BlockingQueue 인터페이스는 Java 5에서 추가되었다. (Deque, BlockingDeque는 6에서 추가되었다.)

※ Synchronized 컬렉션은 객체 자체에 락을 걸어 독점하게되고, Concurrent 컬렉션은 객체 자체 독점하기가 쉽지 않은 단점이 있지만, 장점이 훨씬 더 많다. Concurrent 컬렉션은 컬렉션 전체를 독점하기 위해서는 충분히 신경을 기울여야 한다.

※ Hash를 기반으로 하는 컬렉션은 hashCode()의 해시값이 넓고 고르게 분포되지 못하면 한쪽으로 쏠린 해시 테이블을 사용하게 되는데, 최악의 경우는 단순한 Linked List와 거의 동일한 상태가 될 수 있다.

여러 스레드가 클래스에 접근할 때, 실행 환경이 해당 스레드들의 실행을 어떻게 스케줄하든 어디에 끼워 넣든, 호출하는 쪽에서 추가적인 동기화나 다른 조율 없이도 정확하게 동작하면 해당 클래스는 스레드 안전하다고 말한다.(p.48)

상태 없는(Stateless) 객체는 항상 스레드 안전하다. (p.49)

종종 단순성과 성능이 서로 상충할 때가 있다. 동기화 정책을 구현할 때는 성능을 위해 조급하게 단순성(잠재적으로 안전성을 훼손하면서)을 희생하고픈 유혹을 버려야 한다. (p.65)

일례로, 한 클래스의 멤버 변수를 public으로 노출하여 사용한 경우, 이 변수가 어디서 어떻게 쓰일지 알 수 없으므로, 이 클래스를 Thread safe하게 만들기 위해서는 해당 변수를 사용한 곳을 모두 조사해봐야 한다. 그러나 private으로 숨기고 getter/setter를 사용한 경우 method 레벨에서 동기화를 구현하면 쉽게 Thread Safe한 클래스가 될 수 있다.

따라서, 번거럽더라도 getter/setter를 쓰는 것이 좋다. 너무도 명백하게 내부적으로 잠시 사용하는 inner class 같은 것들까지 getter/setter를 쓰는건 과한 것일 수도 있으니 적절히 판단해서 사용하자.

동기화와 캡슐화에 대한 이야기는 책의 여기저기에서 다른 표현들로 등장한다.

복잡하고 오래 걸리는 계산 작업, 네트웍 작업, 사용자 입출력 작업과 같이 빨리 끝나지 않을 수 있는 작업을 하는 부분에서는 가능한 한 락을 잡지 말아라. (p.65)

(계속)

GWT 프로젝트 디렉토리를 이동하려고 다른 디렉토리에 옮겨놓은 후

다음과 같은 방법으로 다시 불러올 수 있다.

(1) .project 파일이 있는 경우: Import > General > Existing Projects into Workspace

(2) .project 파일이 없는 경우

  New > Other... > GWT Designer > Model

  Next 후에 project Root 디렉토리를 선택하면 .project 파일이 없어도 깔끔하게 import 된다.

http://bhou.wordpress.com/2011/09/13/how-to-install-gnuplot-in-mac-os-x-lion/

readline 라이브러리를 먼저 설치하고 gnuplot을 설치하면 된다.

readline-6.2

$ ./configure --prefix=/usr/local

$ make

$ sudo make install

gnuplot-4.6.3

$ ./configure --prefix=/usr/local --with-readline=/usr/local

$ make

$ sudo make install

클립보드 공유가 가끔씩 안될 때

/usr/bin/VBoxClient --clipboard 를 재시작시키면 된다.

$ ps -ef | grep VBox | grep clipboard

deepblue  9952     1  0 16:44 ?        00:00:00 /usr/bin/VBoxClient --clipboard

$ kill -9 9952

데이터와 서버를 동일한 주소 공간에 배치.

데이터의 키 값과 분산 서버 ID는 동일한 해시 함수로 동일한 주소 공간에 데이터와 노드를 배치.

중앙 서버 없이도 데이터를 관리하는 서버를 찾는 룩업에 성능이 좋다.

클러스터에 참여하는 서버의 추가/제거가 자동으로 이뤄지게 구성할 수 있다.

부하가 집중되지 않고 분산된다는 큰 장점이 있어, 극단적으로 큰 규모의 노드들도 관리할 수 있다.

종래의 순수 P2P에서 채용되었던 방식에서는 수십만 노드 정도가 한계였으나, DHT의 사용으로 수십억개의 노드를 검색범위로 할 수 있게 되었다. 그러나 DHT는 실제 구현이 어렵다.

키 공간 분할(keyspace partition)과 오버레이 네트워크(overlay network)로 구성된다.

- keyspace partition:

  * 분산된 서버에 키를 어떻게 배치시킬 것인가를 결정하는 것

  * 데이터의 hash(key) 값을 이용해 키 영역을 파티셔닝 시킨다.(range, interval)

- overlay network:

  * 물리적인 서버의 연결과 상관없이 논리적인 서버 간의 연결 관리와 키를 담당하는 노드를 찾아가는 메커니즘을 제공.

  * 특정 키를 서비스하는 노드를 찾아가는 라우팅 알로리즘을 제공한다.

DHT를 활용한 대표적인 시스템으로 비트토렌트(DHT를 확장하여 사용), eDonkey 등이 있다.

참고: 클라우드 컴퓨팅 구현 기술(에이콘), 위키백과

redis shard를 virtual node를 입혀보려고 연구중.

사례 및 기술연구를 위해 몇몇 문서를 번역해 본다.

※ 오역에 주의하시고, 잘못 번역된 부분은 댓글로 알려주세요. 

http://www.acunu.com/2/post/2012/07/virtual-nodes-strategies.html

Virtual Nodes Strategies

consistent hasing 에서 각 호스트에 single "token" in a "hash-space" 를 두는 것은 약간 손해가 있는 모델이다.

데이터 추가가 될 때 1/N로 들어가므로 balanced cluster가 된다.

Fig 1. Partitioning of hash-space between 4 hosts in a cluster

그러나 새로운 호스트가 추가되면 unbalanced cluster가 된다.

이를 해결하기 위해 권장되는 방법은 scaling up시 호스트를 2배로 늘리거나, scaling down시 호스트 수를 반으로 줄이는 방법이 있다. 그리고, 모든 다른 호스트로 token을 이동시켜 균형을 잡게 해야 한다. 이 방법은 소규모 클러스터에서나 실행 가능하고, 큰 큐모에서는 사용하기 어렵다.

Fig 2. Balancing a cluster when adding hosts requires moving tokens (top) or doubling the number of hosts (bottom)

이 문제들은 operation들을 매우 복잡하게 만든다. 카산드라 관리자는 balanced load를 보장하는 token들의 주의 깊은 선택을 해야하고, 호스트가 추가될 때 수작업으로 rebalancing을 해줘야 한다. 이런 문제를 해결하는 한가지 방법은 virtual node를 사용하는 것이다. virtual node를 사용하는 consistent hashing schema는 각 호스트가 인접하지 않은 범위에 데이터를 다중으로 둘 수 있게 한다. virtual node를 사용함으로써 얻는 이득은 다음과 같다:

- 클러스터에 추가된 호스트는 서로 다른 호스트로부터 가져온 데이터로 클러스터를 평탄하게(even portion) 만드는 책임을 맡게된다.

- 하나의 호스트에 장애가 발생하면, 클러스터의 다른 호스트들로 로드가 균등 분배될 것이다.

- Rebuilding a dead host will be faster as it will involve every other host (뭔소린지..)

- 호스트에 할당되는 파티션 수는 자신의 용량(capacity)에 의해 결정될 수 있다. 이것은 각기 다른 하드웨어의 사용도 허용하게 한다.

Virtual nodes schemes

대체로 다음 세가지 형태로 분류 해볼 수 있다.

Random token assignment

각 호스트에 T 개의 random token들을 할당한다. 파티션은 각 호스트의 token들의 각각에 할당되고, 파티션은 ring에서 하나의 token과 그 이전 token의 구간(interval)로 정의된다. 호스트가 ring에 추가됐을 때, T개의 random token들이 할당된다. T random tokens which will result in a portion of an existing partition being assigned to that host.(뭔소린지..)

이 방식은 memcached server사이의 분배/분산(distribution)를 위한 libketama[2] 에서 사용되고, T=1일때 카산드라 분산(distribution)을 위한 일반화 방법이다. (역주: 카산드라는 호스트 하나가 토큰 구간(interval) 하나를 전담하게 된다는 뜻인 듯 - 카산드라쪽을 더 알아보자.)

Fig 3. Partitioning by random token assignment

Fixed partition assignment

해시 공간을 균등한 크기 Q개로 나누고, 각 호스트에는 Q/N 개씩 할당한다(N는 호스트 수). 호스트가 추가될 때 다른 호스트에서 몇개를 가져와서 Q/N 비율을 맞춘다. 호스트를 제거할 때는 제거되는 호스트의 파티션을 다른 호스트로 재분배해서 Q/N 비율을 맞춘다.

이 방식은 Dynamo[3]와 Voldemort[4]에서 사용된다.

Fig 4. Fixed partitioning assignment

Automatic sharding

각 호스트에 하나의 token을 할당하고, 각 호스트는 하나의 파티션(token의 interval로 정의됨)을 갖는다. 하나의 파티션이 한계를 초과하면, 새로운 파티션을 생성할 수 있게 해당 파티션의 구간에 새 token이 추가된다. (역주: 즉, 파티션은 token의 interval(구간)을 의미하고, 용량 초과된 파티션에 새로운 구간(token)을 생성한다는 의미. Partition dividing assignment라고 해야 의미가 더 맞지 않을까?)

이 방식은 BigTable[5] 또는 Mongo auto-sharding[6] 에서 수행되는 sharding 방식과 비슷하다.

Fig 5. Automatic sharding: when a partition contains too much data it is split into smaller partitions

Evaluation(평가)

이 스키마들을 평가하기 위해 구현의 차이에 대한 생각(idea)과 이들이 클러스터의 성능에 어떻게 영향을 미치는지에 대한 것들이 필요하다. 이 스키마들의 주요 차이점은 파티션 size와 파티션들의 수이고, 이 두가지가 어떻게 클러스터 size와 데이터 size를 변하게 하는지 살펴본다.

Number of Partitions(파티션 수)

클러스터 메타데이터의 일부분으로써 그것이 저장된 호스트에 파티션의 할당 매핑을 저장해야 한다(must store the assignment mapping of partition to the host on which it is stored). 카산드라에서 이 매핑의 배치는 호스트간에 gossip을 이용한다. 모든 호스트는 클라이언트의 요청은 정확한 replica로 한 홉에 라우팅할 수 있어야 하고, 모든 데이터 위치를 인지하고 있어야 한다. 만약 파티셔닝 스키마가 더 많은 파티션을 요구하면, 카산드라 gossip 시스템에 더 많은 부하와 더 많은 메모리를 사용하게 될 것이다. (If our partitioning scheme results in more partitions then this placement metadata will be larger, will put more load on Cassandra's gossip system, and will use more memory to store.)

Partition Size(파티션 크기)

카산드라에서는 한 번 실행될 때 전체 파티션으로 수행되는 프로세스들이 있다. 예를 들면, 다른 replica의 데이터와 비교할 수 있도록 저장되는 모든 데이터를 위한 digest를 계산하는 repair 같은 것이다. 클러스터에 참여하는 새로운 호스트의 bootstrapping 같은 스트리밍 operation들도 전체 파티션을 읽을 것이다. 매우 큰 파티션을 가지기에 몇가지 불리함(disadvantages)이 있다: 이런 프로세스들 중 하나가 실패하거나 에러가 발생하게 되면 반드시 재시도해야 한다. 큰 파티션에서, 에러로 인해 더 많은 작업이 낭비되게 된다. 새로운 호스트의 bootstrapping(bootstrapping a new host)이 많은 시간을 소비할 때, 한 파티션의 전송 에러는 매우 높은 비용이 들게한다. 작은 파티션에서는 balancing을 위해 클러스터내 다른 호스트에 영향을 주는 이런 operation들을 늦출 수도 있다.

하지만, 우리는 파티션을 매우 작게 만들 수 없다. 많은 작은 파티션들을 읽는 것은 데이터를 전송하기보다 파티션들을 탐색하느라 디스크에서 대부분의 시간을 소비하는 결과를 만들 수 있다. 우리는 random disk access보다는 sequential disk access로 읽으면서 충분히 큰 파티션이 되기를 원한다.

Comparison

Table1은 

<진행중>...

출처: https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks

clock에는 다음 2가지가 있다.

• absolute clock (the time-of-day clock, with a low resolution)
• relative clock (some kind of "high-resolution" counter from which a "free-running" time can be calculated)

현대 컴퓨터에서는 clock과 timer는 큰 차이가 있다.

The resolution of clocks and timers in modern computers is typically very different.

timed events are triggered by operating system controlled interrupts that are normally much more coarse grained (typically 10ms)

Further, systems often have a quite different resolution for the time-of-day clock (often low resolution of 10ms or worse) and the free-running relative clock (microseconds or better), because they are actually derived from quite different pieces of hardware.

absolute clock(time-of-day)는 자바에서 System.currentTimeMillis()로 구현된다.

(System.currentTimeMillis() = 'time-of-day' clock. update resolution is same as the timer interrupt(eg. 10ms).)

The absolute "time-of-day" clock is represented by the System.currentTimeMillis() method, that returns a millisecond representation of wall-clock time in milliseconds since the epoch. As such it uses the operating system's "time of day" clock. The update resolution of this clock is often the same as the timer interrupt (eg. 10ms), but on some systems is fixed, independent of the interrupt rate.

relative-time clock 은 자바에서 System.nanoTime()으로 구현된다. high-resolution이다.

The relative-time clock is represented by the System.nanoTime() method that returns a "free-running" time in nanoseconds.

The nanoTime method uses the highest resolution clock available on the platform, and while its return value is in nanoseconds, the update resolution is typically only microseconds.

However, on some systems there is no choice but to use the same clock source as for currentTimeMillis() - fortunately this is rare and mostly affects old Linux systems, and Windows 98.

자바 타이머 관련 클래스의 해상도.

• The java.util.Timer and java.util.TimerTask - use of currentTimeMillis()
• Java 5.0 ScheduledThreadPoolExecutor (STPE) - use of nanoTime()