[Collection] ArrayList vs Vector
결론
* ArrayList 에 대한 Vector 의 이점을 그나마 꼽자면, 멀티 쓰레드 환경에서의 동기화(synchronization) 를 꼽을 수 있다. Vector 의 소스코드를 살펴보면, 모든 동작(함수)에 대해 일일이 synchronized 가 붙어있다. 이것은 2가지 불행한 결과를 낳게 된다.
1. 프로그래머가 생각한 동기화가 이루어지지 않는다.
일반적으로 동기화는 개별 동작이 아닌 일련의 시퀀스에 대해서 이루어져야 한다. 하지만 Vector 는 단순히 개별 동작에 대한 lock 만 걸려있으므로, 대부분의 경우 Vector 를 사용하더라도 어차피 별도의 lock 이 필요하게 된다.
예를들어, 위 코드의 경우 빨간상자 안의 코드만 lock 이 걸릴 뿐 전체적인 시퀀스에는 걸려있지 않다. 따라서 멀티쓰레드 환경이라면 코드 실행 도중에 얼마든지 다른 thread 에 의해서 vector 가 변경될 수 있고 그로 인해 심각한 문제가 발생할 수 있다.
2. 불필요하게 느려진다.
위에서 언급한 것처럼 일련의 시퀀스에 대해 lock을 한다면 한번만 하면 되지만, vector 를 사용할 경우 불필요한 lock 과 unlock 이 반복된다.
또한 lock 을 원하지 않을 때에도 lock 에 의한 오버헤드가 발생하게 되는 이슈도 있다.
출처
1. GrepCode
* http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/Vector.java
2. StackOverflow
'뿌리튼튼 CS > Java' 카테고리의 다른 글
생성자를 쓰는 이유. 생성자의 필요성 (Why use constructors) (0) | 2016.08.02 |
---|---|
심심풀이 문제1 - Object.equals() (0) | 2016.07.16 |
String vs StringBuilder vs StringBuffer (2) | 2016.01.28 |
Array size in Loops (0) | 2015.07.31 |
Thread ID로 thread 찾기 (get thread by id) (0) | 2015.07.27 |
String vs StringBuilder vs StringBuffer
결론
* StringBuilder 는 사용할 필요가 없다.
* Thread Safe 가 필요하면 StringBuffer, 그렇지 않으면 String
|
String |
StringBuffer |
저장공간 (Storage Area) |
CSP (Constant String Pool) |
힙 (Heap) |
성능 (Performance) |
빠름 (Fast) |
느림 (Slow) |
Thread Safe |
No |
Yes |
Why (작성중)
* StringBuilder 는 사용할 필요가 없다.
작성중
* Thread Safe 가 필요하면 StringBuffer, 그렇지 않으면 String
작성중
출처
1. GrepCode
* http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/String.java
2. Articles & Blogs
* http://javahungry.blogspot.com/2013/06/difference-between-string-stringbuilder.html
'뿌리튼튼 CS > Java' 카테고리의 다른 글
생성자를 쓰는 이유. 생성자의 필요성 (Why use constructors) (0) | 2016.08.02 |
---|---|
심심풀이 문제1 - Object.equals() (0) | 2016.07.16 |
[Collection] ArrayList vs Vector (0) | 2016.02.01 |
Array size in Loops (0) | 2015.07.31 |
Thread ID로 thread 찾기 (get thread by id) (0) | 2015.07.27 |
Array size in Loops
for (int i = 0; i < mArrayList.size(); i++) { | cs |
w3schools 에서 JavaScript 를 공부하다가, 이 흔한 반복문에 의문을 제기하는 글을 보았다.
size() 메서드를 매 loop 마다 실행하는 것은 낭비라는 것이다.
그들은 아래와 같이 개선하는 것을 제안했다.
①
1 2 | int n = mArrayList.size(); for (int i = 0; i < n; i++) { | cs |
② 혹은 scope 최소화 측면에서 조금더 개선된
for (int i = 0, n = mArrayList.size(); i < n; i++) { | cs |
하지만.
그렇다면 내가 봐왔던 뛰어난 코드들은 왜 저런식으로 코딩하지 않았을까?
의문이 들어 ArrayList 소스코드를 직접 열어보았다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | package java.util; public class ArrayList<E> extends ... { ... private int size; ... ... public int size() { return size; } ... } | cs |
그렇다. size() 는 단순히 size 변수값을 반환하는 O(1) 의 메서드인 것이다.
당연하게도, 미련하게 처음부터 count 하는 O(n) 이 아닌 것이다.
게다가 JVM 이 똑똑하여서 loop 내에서 size 값이 변하지 않는다는 것을 알고 있으며,
따라서 자동으로 최적화를 한다고 한다.
덧붙여서, ArrayList 객체가 아닌 일반 array (ex. int[]) 의 length 도 같은 방식으로 구현이 되어있다고 한다.
나의 결론 :
좋은 접근이지만 결론적으로는 가독성만 떨어질 뿐이다.
출처들
그들의 주장들:
http://www.w3schools.com/js/js_performance.asp
http://egloos.zum.com/benelog/v/1382604
우리의 주장들:
'뿌리튼튼 CS > Java' 카테고리의 다른 글
생성자를 쓰는 이유. 생성자의 필요성 (Why use constructors) (0) | 2016.08.02 |
---|---|
심심풀이 문제1 - Object.equals() (0) | 2016.07.16 |
[Collection] ArrayList vs Vector (0) | 2016.02.01 |
String vs StringBuilder vs StringBuffer (2) | 2016.01.28 |
Thread ID로 thread 찾기 (get thread by id) (0) | 2015.07.27 |
Thread ID로 thread 찾기 (get thread by id)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | ThreadGroup rootGroup = Thread.currentThread().getThreadGroup(); ThreadGroup parentGroup; while ((parentGroup = rootGroup.getParent()) != null) { rootGroup = parentGroup; } Thread[] threads = new Thread[rootGroup.activeCount()]; while (rootGroup.enumerate(threads, true) == threads.length) { threads = new Thread[threads.length * 2]; } for (Thread t : threads) { if (t.getId() == targetID) { /* found it */ } } | cs |
출처 :
'뿌리튼튼 CS > Java' 카테고리의 다른 글
생성자를 쓰는 이유. 생성자의 필요성 (Why use constructors) (0) | 2016.08.02 |
---|---|
심심풀이 문제1 - Object.equals() (0) | 2016.07.16 |
[Collection] ArrayList vs Vector (0) | 2016.02.01 |
String vs StringBuilder vs StringBuffer (2) | 2016.01.28 |
Array size in Loops (0) | 2015.07.31 |