Strong Root

결론

* ArrayList 가 항상 옳다





Why

* 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-b27/java/util/ArrayList.java

 * http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/Vector.java

2. StackOverflow

 * http://stackoverflow.com/questions/1386275/why-is-java-vector-class-considered-obsolete-or-deprecated



결론

* 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

 * http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/AbstractStringBuilder.java

 * http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/StringBuilder.java

 * http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/StringBuffer.java


2. Articles & Blogs

 * http://javahungry.blogspot.com/2013/06/difference-between-string-stringbuilder.html

 * https://slipp.net/questions/271

 * http://namocom.tistory.com/360

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


우리의 주장들:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/ArrayList.java

http://stackoverflow.com/questions/863469/what-is-the-time-complexity-of-a-size-call-on-a-linkedlist-in-java

http://stackoverflow.com/questions/17998386/time-complexity-or-hidden-cost-of-array-name-length-in-java

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






출처 :

http://stackoverflow.com/a/1323480

http://stackoverflow.com/a/6668121