Brian's World

1. SMC

1. 맥을 종료시킵니다.

2. 맥세이프를 연결해 전원을 공급합니다.

3. 키보드의 shift + control + option + 전원 버튼을 동시에 클릭합니다.

4. 잠시 후 손을 떼고 맥을 부팅시킵니다.

이때, 맥세이프의 LED 색상이 변하는 것은 정상적으로 리셋되었다는 신호입니다.

2. PRAM

1. 맥을 종료합니다.

2. 다시 맥을 부팅하는데, 이때 키보드의 command + option + P + R 버튼을 동시에 누릅니다.

3. 버튼을 누른 상태에서 맥의 부팅음이 2~3번 반복되면 손을 뗍니다.(시스템은 자동으로 재시작 됩니다.)

내 블러그에 1년만에 온듯 하다.

시간이 없었던 것일까 아니면 게을러져서 일까?

요즘 이것 예전과 같이 한번에 한권의 책을 읽는게 아니고 이책 저책을 번갈아 가며 읽는다.

그 중 이건 좀 정리하고 가야할 것 같아 오랜만에 블러그를 방문했다.

백화제방

온갖 꽃이 일시(一時)에 핀다는 뜻으로, 갖가지 학문(學問)이나 예술(藝術)이 함께 성(盛)함의 비유(比喩ㆍ譬喩)

장하준 교수님께서는 경제학파 칵테일을 권하였지만 내 입장에서는 9개의 학타를 다시 칵테일화 하여 여러개로 분리하여 이해하는 것이 어려운 일이라 각 9개의 학파에 한 문장 요약을 이곳에 정리하여 필요할 때 읽어봐야 겠다.

1. 고전주의 학파: 시장은 경쟁을 통해 모든 생산자를 감시하기 때문에 그냥 내버려두면 된다.

2. 신고전주의 학파: 각 개인은 자신이 무엇을 하는지 잘 알고 행동하므로, 시장이 오작동할 때를 제외하고는 놔두는 것이 좋다.

3. 마르크스 학파: 자본주의는 경제 발달의 막강한 동력이지만, 사유 재산이 더 이상의 발전을 가로막는 장애물이 되면서 저절로 무너질 것이다.

4. 개발주의 전통: 후진 경제에서는 모든 것을 시장에 맡겨 놓으면 개발이 불가능하다.

5. 오스트리아 학파: 모든 것을 충분히 아는 사람은 없으므로, 아무한테도 간섭하면 안 된다.

6. (신)슘페터 학파: 자본주의는 경제 발달의 막강한 동력이자만, 기업이 대형화하고 관료주의화하면서 쇠락하게 되어 있다.

7. 케인스 학파: 개인에 이로운 것이 전체 경제에는 이롭지 않을 수도 있다.

8. 제도 학파: 신제도학파? 구제도학파?: 개인이 사회적 규칙을 바꿀 수 있다 해도 결국 개인은 사회의 산물이다.

9. 행동주의 학파: 인간은 충분히 똑똑하지 않기 때문에 규칙을 통해 의도적으로 선택의 자유를 제한해야 한다.

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() 메소드를 호출 함