[Java Concurrency] 객체공유 [Java Concurrency] 객체공유 3.1. 가시성 - 일반적으로 특정 변수의 값을 가져갈 때 다른 스레드가 작성한 값을 가져갈 수 있다는 보장도 없고, 심지어는 값을 읽지 못 할 수도 있다. 메모리상의 공유된 변수를 여러 스레드에서 서로 사용할 수 있게 하려면 반드시 동기화 기능을 구현해야 한다. - 재배치(reordering) 현상을 조심해야 한다. 재배치 현상은 특정 메소드의 소스코드가 100% 코딩된 순서로 동작한다는 점을 보장할 수 없다는 점에 기인하는 문제이다. 단일 스레드로 동작할 때는 차이점을 전혀 알아챌 수 없지만 여러 스레드가 동시에 동작하는 경우에는 확연하게 나타날 수 있다. - 동기화 기능을 지정하지 않으면 컴파일러나 프로세서, JVM 등이 프로그램 코드가 실행되는 순서를 임.. 2017. 4. 17. [Effective Java] 독자적인 직렬화 형태의 사용을 고려하자 [Effective Java] 독자적인 직렬화 형태의 사용을 고려하자 - 클래스를 설계할 때 클래스가 Serializable 을 구현하면서 기본 직렬화 형태를 사용한다면, 나중에 함부로 버릴 수 없고, 그 직렬화 형태를 계속 유지해야 할 가능성이 높다. - 적합 여부를 우선적으로 고려해보고 기본 직렬화 형태를 수용하자. 기본 직렬화 형태는 유연성, 성능, 정확성의 관점에서 타당하다는 결정이 섰을 때 사용해야 한다. 일반적으로 말하면, 우리가 독자적인 직렬화 형태를 설계한다고 할 때 하게될 인코딩과 대부분 같은 경우에만 기본 직렬화 형태를 사용해야 한다. - 이상적인 객체 직렬화 형태는 그 객체가 표현하는 논리적 데이터만 포함한 것이다. - 기본 직렬화 형태는 객체의 물리적 표현이 논리적인 내용과 동일할 .. 2017. 3. 23. [Effective Java] Serializable 인터페이스를 분별력 있게 구현하자. [Effective Java] Serializable 인터페이스를 분별력 있게 구현하자. - 객체 직렬화(object serialization) API 는 객체를 바이트 스트림으로 인코딩하고, 인코딩된 바이트 스트림으로부터 객체를 복원(디코딩) 하는 프레임워크이다. - 객체를 바이트 스트림으로 인코딩하는 것을 직렬화(serializing)이라 하고, 그 반대의 절차를 역직렬화(deserializing)이라고 한다. - 객체가 일단 직렬화되면, 인코딩된 객체는 향후에 역직렬화 하기 위해 하나의 실행 중인 VM 에서 다른 VM 으로 전송되거나 디스크에 저장될 수 있다. 직렬화는 원격 통신을 위한 표준 통신 회선 수준의 객체 표현을 제공한다. 직렬화 프록시는 effective java 의 직렬화 주제중 가장 .. 2017. 3. 21. [Effective Java] 스레드 스케쥴러에 의존하지 말자 [Effective Java] 스레드 스케쥴러에 의존하지 말자 - 많은 스레드가 runnable 상태일 때는 어떤 스레드를 실행시킬 것인지, 그리고 얼마 동안 실행시킬 것인지를 스레드 스케쥴러가 결정한다. 운영체제에서는 공정하게 그런 결정을 내리려고 하겠지만, 그 정책은 서로 다를 수 있다. 따라서 잘 작성한 프로그램은 그런 정책의 상세한 내용에 매달려서는 안 된다. 정확성이나 성능을 스레드 스케줄러에 의존하는 프로그램이라면 그 어떤 것도 이식성이 없어질 가능성이 크다. - 강력하고, 응답성이 좋고, 이식성이 있는 프로그램을 작성하는 가장 좋은 방법은, runnable 상태의 평균 스레드 개수가 프로세서의 개수보다 그리 크지 않게 하는 것이다. 이렇게 하면 스레드 스케줄러는 선택의 여지 없이 runnab.. 2017. 3. 17. [Effective Java] 복구 가능 상황에서는 checked 예외를 사용하고, 런타임 예외는 프로그램 에러에 사용하자. 복구 가능 상황에서는 checked 예외를 사용하고, 런타임 예외는 프로그램 에러에 사용하자. - 자바 언어는 다음 세 종류의 예외를 던질 수 있다. checked exception, runtime exception, error - 메소드 호출자가 당연히 예외 복구를 할 수 있는 상황에서는 checked 예외를 사용하자. checked 예외를 던지면 그 메소드 호출자가 catch 문에서 예외를 처리하거나 또는 외부로 넘겨야 한다. API 사용자가 checked 예외와 만났다는 것은, 그런 상황을 복구하라는 지시를 그 API 설계자로부터 받은 것이다. - unchecked exception 인 runtime exception 과 error 는 catch 할 필요가 없고, 일반적으로 catch 해서도 안 된.. 2017. 2. 21. [Effective Java] 예외 상황에서만 예외를 사용하자. [Effective Java] 예외 상황에서만 예외를 사용하자. - 예외는 예외 상황을 대비해 설계된 것이므로, JVM 을 만드는 회사가 예외 처리 속도를 빠르게 하려고(우리가 명시적으로 검사하는 것만큼) 매달릴만한 일이 아니다. try-catch 블록 내부에 코드를 넣으면, 여러 종류의 JVM 이 해 줄 수 있는 나름의 최적화를 못하게 하는 부작용이 생길 수 있다. 배열을 반복 루프 처리하면서 정상적인 루프 종료 검사를 하는 표준 이디엄 코드가 반드시 중복 검사를 하는 것은 아니다. 근래의 JVM들에서는 그런 코드를 최적화한다. - 예외는 예외적인 상황에서만 사용해야 한다. 절대로 정상적인 흐름 제어에 사용하면 안된다. - 잘 설계된 API에서는 클라이언트가 예외를 사용해서 정상적인 흐름 제어를 하게끔.. 2017. 2. 20. [Effective Java] 잘 판단해서 최적화하자 [Effective Java] 잘 판단해서 최적화하자 - 최적화에 대한 명언이 있다. 더 많은 컴퓨팅 죄악이 다른 어떤 한 가지 이유(무지로 인한 어리석음을 포함해서)보다는 효율성(달성이 안 되는)의 이름으로 저질러진다. 사소한 효율성은 잊어야 한다. 97%의 시간에 대해 논하자. 성급한 최적화는 모든 죄악의 근원이다. 최적화에 관한 두 가지 규칙을 따르자. 규칙 1. 하지 말자. 규칙 2. (전문가에 한해서). 아직 하지 말자. 정말 최적화되지 않은 솔루션이 있을 때까지는. - 성급한 최적화는 얻는 것보다 잃는 것이 더 많기 쉽다. 최적화를 하면서 빠르지도 않고 제대로 동작하지도 않으며, 문제를 쉽게 해결하기도 어려운 소프트웨어를 만들기도 쉽다. - 성능 때문에 훌륭한 아키텍쳐 원리를 포기하지 말자. .. 2017. 2. 16. [Effecitve Java] 네이티브 메소드를 분별력 있게 사용하자. [Effecitve Java] 네이티브 메소드를 분별력 있게 사용하자. - JNI 는 네이티브 메소드를 호출할 수 있게 해준다. 네이티브 메소드는 C, C++ 과 같은 네이티브 프로그래밍 언어로 작성한 특별한 메소드를 말한다. - 지금까지 네이티브 메소드의 주용도는 세가지였다. 레지스트리와 파일 락 같은 특정 플랫폼 관리시스템의 접근을 제공 레거시 데이터를 제공할 수 있는 레거시 코드로 된 라이브러리의 접근 제공 성능 향상을 위해 어플리케이션의 일부를 네이티브 언어로 작성하는 데 사용 - 자바가 발전하면 기존의 네이티브 메소드만이 할 수 있었던 일을 많이 대체하였다. java.util.prefs 패키지가 레지스트리 기능을 제공. java.awt.SystemTray 가 데스크톱 시스템의 휴지통 영역의 접근.. 2017. 2. 14. WeakHashMap 에 대해 제대로 이해하자. WeakHashMap 에 대해 제대로 이해하자. - WeakHashMap 은 일반적인 HashMap 과 동일하지만 key 가 weak reference 된 형태이다. - WeakHashMap 을 가장 잘 이해하는 용어는 이렇다. "더 이상 일반적인 방법인 key 로 value 를 retrive 할 수 없을 때 key/value pair 를 제거한다." 따라서 string 은 WeakHashMap 의 key 로 적합하지 못하다. string 은 JVM 에 의해 다른 곳에 store 되어 항상 strong reference 로 남을 것이다. 다시 말하자면 string 을 key 로 사용할 것이라면 WeakHashMap 을 쓸 이유가 없다. - Primitive Boxing object 들도 key 로 사용하.. 2016. 10. 13. 반응형 이전 1 2 3 4 다음
