주니어 개발자 성장기

문제 상황 주로 데이터베이스에서 발생하는 문제이다. 한 프로세스가 DB에 Write 중일 때 다른 프로세스가 접근하면 안된다. Read는 동시에 여럿이 해도 된다. 해결법 Writer가 DB에 접근 허가를 아직 얻지 못한 상태에서는 모든 대기중인 Reader들을 다 DB에 접근하게 해준다. Writer는 대기 중인 Reader가 하나도 없을 때 DB 접근이 허용된다. 일단 Writer가 DB에 접근 중이라면 Reader들은 접근이 금지된다. Writer가 DB에서 빠져나가야만 Reader의 접근이 허용된다. 여기서 Shared Data는? DB 자체 readcount - 현재 DB에 접근 중인 Reader의 수 두 가지 동기화 변수(세마포어) Mutex 공유 변수 readcount를 접근하는 코드(cri..

Bounded Buffer Problem (유한 버퍼 문제) Producer-Consumer Problem(생산자-소비자 문제) 이라고도 한다. Producer 데이터를 버퍼에 삽입 Consumer 데이터를 버퍼에서 제거 여기서 Shared Data는? 버퍼 자체 버퍼 조작 변수(empty와 full 버퍼의 시작 위치) 문제의 원인 다수의 Producer / Consumer가 버퍼에 데이터를 삽입, 제거할 수 있기 때문이다. 버퍼 자체의 경쟁 상황 발생 버퍼가 가득 차거나 빌 경우 추가/삭제가 불가능함을 알아야 한다. 두 가지 세마포어가 필요 Mutual exclusion shared data의 동기화 때문에 Binary semaphore가 필요 (2번 스텝) 다수의 주체가 동시에 버퍼를 변경할 수 없도..

개요 가변인수와 제네릭을 함께 사용하면 힙 오염이 발생할 여지가 있으므로 신중히 사용해야만 한다.(2가지 조건을 준수하자.) 힙오염이 발생 가능한 이유? 가변인수를 사용하게되면 원래는 불가능한 제네릭으로 배열을 만드는 것이 가능해진다. 책에서 힙오염이 발생한다고 지목한 예제코드를 보자. // 코드 32-1 제네릭과 varargs를 혼용하면 타입 안전성이 깨진다! (191-192쪽) static void dangerous(List... stringLists) { List intList = List.of(42); Object[] objects = stringLists; objects[0] = intList; // 힙 오염 발생 String s = stringLists[0].get(0); // ClassCas..

개요 이펙티브 자바를 공부하던 중 익명 클래스, 지역 클래스, 중첩 클래스 등의 개념이 등장해서 구글링을 하던 중 이해가 잘되는 레퍼런스들을 찾았다. 서버 개발에서는 정적 멤버 클래스, 비정적 멤버 클래스를 제외하고는 거의 쓰일 일이 없을거라 예상한다. 그렇지만 아래 레퍼런스에 의하면 안드로이드 스튜디오에서 쓰일 수도 있다고 한다.(확실하지는 않음) https://sjh836.tistory.com/145 중첩클래스를 알아보자 (내부클래스, 정적 중첩클래스, 지역클래스, 익명클래스) 일반클래스는 Package member class 라고들 하며, 아래 항목에서 제외했다. 구글링해보면 클래스간에 관계나 큰 틀에서의 구조를 안잡고 나열하는 식이 많은 것 같다ㅋㅋ1. 중첩 클래스는 왜 쓰는가? sjh836.ti..

개요추상클래스 대신 인터페이스를 우선적으로 활용하자. 인터페이스의 장점이 더 많다. 기존 클래스에도 손쉽게 새로운 인터페이스를 구현해넣을 수 있다.2개 이상의 클래스를 동시에 상속받는 것은 불가능하다. 여러 클래스를 상속 받아야 하는 클래스가 이미 추상 클래스를 상속받았다면 이미 둘 간의 계층구조가 생겨 상속에 어려움이 생긴다. 반면 인터페이스는 한 클래스에서 여러번 구현하게 할 수 있고 기존에 어떤 클래스를 상속받고 있는 지에 관계 없이 기능을 추가할 수 있다. 인터페이스는 믹스인이 가능하다. 믹스인이란 클래스가 구현할 수 있는 타입으로, 믹스인을 구현한 클래스에 원래의 ‘주된 타입’ 외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 준다. 인터페이스를 통해 어떤 클래스의 갖고 있는 주된 역할외에 ..

개요이전 아이템에서 상속 대신 컴포지션을 사용하라고 했지만 그래도 상속은 객체지향 프로그래밍의 가장 큰 특징들 중 하나이다. 코드의 재사용성을 높이는 방법 중 하나이다. 따라서, 상속을 허용할 때는 ‘잘’하는 것이 필요하다. 상속용 클래스는 내부 구현을 문서로 남겨야 한다. 하지만 이런 식은 “좋은 API문서란 ‘어떻게’가 아닌 ‘무엇’을 하는지를 설명해야 한다”라는 격언과는 대치되지 않나? 그렇다. 상속이 캡슐화를 해치기 때문에 일어나는 안타까운 현실이다. - 이펙티브 자바 3판 123p 어차피 상속으로 인해 캡슐화가 깨지기 때문에 내부 구현을 제대로 알아야 적절하게 오버라이딩할 수 있기 때문에, 상속용 클래스는 내부 구현을 자세하게 문서로 남겨야 한다는 것이다. 문서에 @implSpec과 함께 내부 ..