Brian's World

SAX/DOM

SAX                 DOM

속도 1.929ms     6,468ms <- 같은 파일의 경우 3배정도 차이

메모리 56mb         292mb <- 같은 파일의 경우 5배정도 차이

같은 XML 파일을 처리할 때 SAX가 속도면에서나 메모리면에서나 빠르다.

하지만 다루기는 DOM이 편하고 쉽다.

JAVA IO/NIO (10mb 읽기/쓰기)

    버퍼 없는 FileReader 버퍼있는 FileReader BufferedReader(줄 단위로 읽기 제공)

속도     2,480ms (느림)         400ms (빠름)         350ms (조금 더 빠름)

    BufferedReader(IO) MappedByteBuffer(NIO) TransferTo(NIO)

속도     422ms 320ms         310ms

프로그램을 만들다 보면 IO를 많이 사용한다 .ex) config 파일을 읽는 일 등

그래서 설정파일을 읽을 때마다 수정되었는지 확인한다면 이를 데몬(Daemon) 스레드를 하나 생성하여 5~10분마다 확인하게 하는 것이 수정되었는지 안되었는지 확인하는 것보다 속도를 향상시킬 수 있다.

NIO가 IO보다 빠른 이유는 non-blocking(비봉쇄)과 asynchronous(비동기) 때문이다.

참조. http://devsw.tistory.com/142

반복문

for의 3가지 방법

for1. for(int i =0; i < v.size; i++)

for2. int vSize = v.size; for(int i =0; i < vSize; i++)

for3. for(String temp;v)

속도 for3 < for1 < for2 (가장 편하지만 for3이 가장 느리고 매번 사이즈 값을 가져오는 for2가 느리고 for1이 짱)

Static

Static 초기화 블록

static staticVal;

static {

staticVal = “Static Value”;

}

Static과 메모리 릭

Why?? => Collection 객체를 Static으로 잡는 경우(가비지 컬렉터가 잡아낼 수 없고 데이터는 늘어만 날수 있다)

인스턴스 확인

Object obj; if(obj instanceof java.math.BigDecimal) {} (BigDecimal 클래스의 인스턴스인지 확인)

Collection

동기화= 다중 스레드에서 데이터 처리를 보장

동기화되어 있는 클래스는 Vector와 Hashtable 밖에 없지만 다음과 같이해서 동기화 처리가 된다.

Set s = Collections.synchronizedSet(new HashSet(…));

블로킹 큐= 크기가 정해져있는 큐에 공간이 더이상 없을때, 공간이 생길때까지 대기

Set

속도: TreeSet < HashSet < LinkedHashSet (많이 차이 없음)

List

속도: ArrayList < LinkedList  < Vector (별 차이 없지만 LinkedList에서 값을 가져올때 poll대신 get을 사용하면 많이 느려진다.)

Map

속도: TreeMap >> HashMap > HashTable > LinkedHashMap (TreeMap 이 좀 느리고 나머지는 비슷)

사실 모두 속도가 비슷해서 어떤걸 사용해도 별 상관없다 하지만 안정적인걸 봤을때 Sun이 선정한 인터페이스별 클래스는 다음과 같다.

Set -> HashSet

List -> ArrayList

Map -> HashMap

Queue -> LinkedList

String

String 값의 비교(==, equals, compareTo, Collator 클래스)

1. ==                        -> 값과 상관없이 같은 오브젝트인지 확인

2. equals                 -> 값이 같은지 확인

3. compareTo        -> int 값 반환 (같으면 0 다르면 크기에 따라 음수와 양수로 나누어짐)

4. Collator클래스    -> 자연어를 비교하여 순서 매길 때

StringBuffer vs        StringBuilder

스레드  안전                                 단일 스레드에서만 보장

속도  String보다 완전빠름 StringBuffer보다 좀 더 빠름

메모리  String보다 완전적음 StringBuffer와 같음

이유 = String의 경우 + 연산을 할때마다 세로운 주소지에 더해진 String 값을 저장한다. 하지만 StringBuffer와 StringBuilder의 경우 처음 주소지에 값만 추가된다.새로 메모리를 할당하고 값을 옮겨갈 필요가 없다.

비교

- String은 짧은 문자열을 더할 경우 사용한다.

- StringBuffer는 스레드에 안전한 프로그램이 필요할 때나, 개발 중인 시스템의 부분이 스레드에 안전한지 몰르 경우 사용하면 된다.

- StringBuilder는 스레드에 안전한지 여부가 전혀 관계 없는 프로그램을 개발할 때 사용하면 좋다.

생성자

- StringBuffer()                 => 기본 용량 16개의 char 이다.

- StringBuffer(CharSequence seq) => CharSequence는 CharBuffer, String, StringBuffer, StringBuilder의 인터페이스이며 생성된 StringBuffer는 실재로 seq에 대한 값을 갖는다.

- StringBuffer(int capacity) => capacity = 용량

- StringBuffer(String str) => str 값을 갖는 StringBuffer 생성

1. 팩토리 메소드 패턴

추상클래스 Creator의 구상클래스인 ConcreteCreator가 결국 Product 인터페이스의 

구상클래스인 ConcreteProduct를 이용해 Product를 생산해 낸다.

객체의 생성을 서브클래스에 맡긴다.

Main() {

Creator newFactory = new ConreteCreator();

Product newProduct = new newFactory.factoryMethod();

}

 

2. 추상 팩토리 패턴

Factory 인터페이스를 통해 제품A와 제품 B를 받을 수 있다. 이때, Factory의 구상 클래스가 

어느것이냐에 따라 이를 구성하고 있는 제품의 종류가 정해 진다.

 

3. 팩토리 메소드 패턴과 추상 팩토리 패턴

- 추상 팩토리 패턴: 객체의 구성(Composition)을 통해 제품을 생성 

-> 제품군을 만들때 사용 가능

- 팩토리 메소드 패턴: 클래스를 써서 제품을 생성

데코레이터 패턴

- 기본 추상구성요소를 가지고 기능을 추가 및 수정

생성자

FileInputStream(File file)

FilterInputStream(InputStream in)

LineNumerInputStream(InputStream in)

Ex) InputStream in = 

LineNumerInputStream(new BufferedInputStream(new FileInputStream(file)))

1. FileInputStream = 데코레이터로 포장될 구성요소 -> 파일을 읽어들임

2. BufferedInputStream = 구상데코레이터 -> 속도향상(buffer사용), 한줄씩 읽어들이는 readLine() 메소드 제공

3. LineNumberInputStream = 구상데코레이터 -> 행번호를 붙여줌

ex) 자바 I/O

옵저버패턴

- 관리 받을 클래스들이 Oserver 인터페이스를 구현하며 이때 Subject 한곳에서 이들을 관리하고 이벤트 같은 사건이 있을 때 모든 객체의 update() 메소드를 호출 함

아이터레이터 패턴

스트러티지 패턴 => 위임