본문 바로가기
[Objective-C] 카테고리 개념 ( Category ) [Objective-C] 카테고리 개념 ( Category ) http://soooprmx.com/wp/archives/2436#disqus_thread -기존에 정의된 어떤 클래스를 쉽게 확장할 수 있게 해준다.카테고리를 적용하면, 이 녀석을 사용하는 녀석은 물론 상속받는 녀석까지 확장된 기능을 사용할 수 있다. -왜 이름이 카테고리냐하면...범용적으로 사용되는 Class 를 확장해서 사용을 한다고 생각을 한다면, 이 기능 저 기능 다 쑤셔넣어서 유지보수가 어려운 코드가 될 수 있다.이 녀석을 SomeClassA, SomeClassA+Network, SomeClass+Graphic 과 같이 카테고리화해서 확장해서 사용하는 것을 목적으로 설계되었기 때문에, 이 녀석을 카테고리라고 부른다. -header .. 2017. 7. 18.
[Java Concurrency] 동기화 클래스 구현 14.1. 상태 종속성 관리 - 병렬 객체의 상태 종속적인 메소드는 선행 조건이 만족하지 않았을 때 오류가 발생하는 문제에서 비켜날 수도 있겠지만, 비켜나는 일보다는 선행 조건을 만족할 때까지 대기하는 경우가 많아진다. - 자바에 내장된 조컨 큐 메커니즘(condition queue mechanism)은 실행 중인 스레드가 특정 객체가 원하는 상태에 진입할 때까지 대기할 수 있도록 도와주며, 원하는 상태에 도달해서 스레드가 계속해서 실행할 수 있게 되면 대기 상태에 들어가 있던 스레드를 깨워주는 역할도 담당한다. - 일단 선행 조건을 만족하지 않았다면 락을 다시 풀어줘야 다른 스레드에서 상태 변수를 변경할 수 있다. 만약 락을 풀어주지 않고 계속 잡고 있다면 다른 스레드에서 상태 변수의 값을 변경할 수 .. 2017. 5. 8.
[Java Concurrency] 명시적인 락 13.1. Lock 과 ReentrantLock - Lock 인터페이스는 암묵적인 락과 달리 조건 없는(unconditional)락, 폴링 락, 타임아웃이 있는 락, 락 확보 대기 상태에 인터럽트를 걸 수 있는 방법 등이 포함돼 있으며, 락을 확보하고 해제하는 모든 작업이 명시적이다. - public interface Lock{ void lock(); void lockInterruptibly() throws InterruptedException; boolean tryLock(); boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException; void unlock(); Condition newCondition(); } - Reentran.. 2017. 5. 5.
[Java Concurrency] 스레드 풀 활용 [Java Concurrency] 스레드 풀 활용 8.1. 작업과 실행 정책 간의 보이지 않는 연결 관계 - 일정한 조건을 갖춘 실행 정책이 필요한 작업에는 다음과 같은 것들이 있다. 의존성이 있는 작업 스레드 한정 기법을 사용하는 작업 응답 시간이 민감한 작업 ThreadLocal 을 사용하는 작업 - 스레드 풀은 동일하고 서로 독립적인 다수의 작업을 실행할 때 가장 효과적이다. - 특정 작업을 실행하고자 할 때 그에 맞는 실행 정책을 요구하는 경우도 있고, 특정 실행 정책 아래에서는 실행되지 않는 경우도 있다. 다른 작업에 의존성이 있는 작업을 실행해야 할 때는 스레드 풀의 크기를 충분히 크게 잡아서 작업이 큐에서 대기하거나 등록되지 못하는 상황이 없도록 해야 한다. 스레드 한정 기법을 사용하는 작업.. 2017. 4. 27.
[Java Concurrency] 중단 및 종료 #2 [Java Concurrency] 중단 및 종료 #2 7.3. 비정상적인 스레드 종료 상황 처리 - 스레드를 예상치 못하게 종료시키는 가장 큰 원인은 바로 RuntimeException 이다. RuntimeException 은 대부분 프로그램이 잘못 짜여져서 발생하거나 기타 회복 불가능의 문제점을 나타내는 경우가 많기 때문에 try_catch 구문으로 잡지 못하는 경우가 많다. RuntimeException 은 호출 스택을 따라 상위로 전달되기보다는 현재 실행되는 시점에서 콘솔에 스택 호출 추적 내용을 출력하고 해당 스레드를 종료시키도록 되어 있다. - 스레드 풀에서 사용하는 작업용 스레드나 스윙의 이벤트 처리 스레드와 같은 작업 처리용 스레드는 항상 Runnable 등의 인터페이스를 통해 남이 정의하고.. 2017. 4. 26.
[Effective Java] 방어 가능한 readObject 메소드를 작성하자 [Effective Java] 방어 가능한 readObject 메소드를 작성하자 - Serializable 하게 만들고 싶은 class 의 물리적 표현과 논리적 표현이 같다고 해도, 무조건 implements Serializable 을 붙이는 것이 능사가 아니다. readObject 는 바이트 스트림 인자 하나만 받는 생성자라고 볼 수 있는데 누군가가 고의적으로 이상한 바이트 스트림을 제공할 경우 문제가 될 수 있다. 따라서 readObject 메소드를 만들고, defaultReadObject() 를 수행 후, 역직렬화되는 객체의 유효성을 검사해야 한다. 만일 유효성 검사에 실패하면, readObject 메소드에서 InvalidObjectException 예외를 발생시켜야 한다. - 위의 방법으로 유효성.. 2017. 3. 24.
[Effective Java] 스레드 그룹을 사용하지 말자. [Effective Java] 스레드 그룹을 사용하지 말자. - 스레드, 락, 모니터에 더하여 스레드 시스템에서 제공하는 기본 추상체가 스레드 그룹(thread group) 이다. 스레드 그룹은 원래 보안을 목적으로 애플릿을 격리시키는 메커니즘으로 구상되었다. 그러나 실제로는 그런 기대를 충족시키지 못해 자바 보안 모델의 표준에서 언급되지 않을 정도로 쇠약하다. - 스레드 그룹은 기능이 별로 없다. 단지 Thread 클래스의 기본 메소드들을 여러 스레드가 포함된 그룹에 일괄로 한번에 적용할 수 있게 해준다. 그런 기본 메소드들 중 상당 수는 이미 사용금지 되었으며 남은 메소드들은 사용되는 경우가 드물다. - ThreadGroup 클래스의 API 메소드는 스레드 안전 관점에서도 빈약하다. 하나의 스레드 그.. 2017. 3. 20.
[Effective Java] 스레드 안전을 문서화 하자. [Effective Java] 스레드 안전을 문서화 하자. - 클래스 행동을 문서화하지 않으면, 프로그래머는 가정에 의존해서 그 클래스를 사용해야 한다. 만일 그런 가정들이 잘못되면, 그로 인한 프로그램은 불충분한 동기화나 과도한 동기화를 하게 될 것이다. 어떤 경우든, 심각한 에러가 유발될 수 있다. - 메소드 선언부의 synchronized 변경자는 메소드의 상세 구현 부분이지 외부로 제공되는 API 가 아니다. 즉 Javadoc 에 synchronized 가 공개되지 않는다. synchronized 변경자가 있다는 것이 스레드 안전을 문서화하기에 충분한 것은 아니다. 동시적 사용을 안전하게 하려면, 해당 클래스가 어떤 수준의 스레드 안전을 지원하는지 명확하게 문서화해야 한다. - 다음은 스레드 안전.. 2017. 3. 14.
[Effective Java] 지나친 동기화는 피하자 [Effective Java] 지나친 동기화는 피하자 - 지나친 동기화는 성능을 저하시키고 교착상태(dead lock)을 유발시키며, 심지어 예기치 않은 행동을 초래할 수 있다. - 동기화된 메소드나 블록 안에서 절대로 클라이언트에게 제어권을 넘기면 안 된다. 즉, 동기화된 영역 내부에서는 오버라이딩된 메소드를 호출하지 않아야 하며, 함수 객체의 형태로 클라이언트가 제공하는 메소드도 호출하지 말아야 한다. 동기화된 영역을 갖는 클래스의 관점에서 그런 메소드들은 매우 이질적인 녀석들이다. 그 메소드가 무슨 일을 하는지 알지 못하며, 이질적인 일을 하는 것을 제어하지도 못한다. 외계인 메소드가 하는 일에 따라 다르겠지만, 동기화된 영역에서 그 메소드를 호출하면 예외나 dead lock 또는 데이터 손상까지 .. 2017. 3. 9.
반응형