xor eax, eax

기본적인 개념 모든 I/O (File, Network, etc.)는 커널 레벨에서 관리된다. 애플리케이션 레벨에서 직접 I/O를 할 수 없고 모든 I/O는 커널에 System call하여 요청을 하고 그에 따른 응답을 받는 구조로 구성되어 있다는 뜻이다. 이때 애플리케이션과 커널이 소통하는 방식을 정함에 있어 블로킹과 논블로킹, 동기와 비동기로 나뉘게 된다. 애플리케이션에서 커널의 응답을 기다리면 블로킹, 기다리지 않고 다른 작업을 진행하면 논블로킹 작업의 순서를 애플리케이션에서 결정하여 순서가 보장되면 동기, 커널에서 결정하고 애플리케이션에 작업의 완료를 통보하면 비동기이다. 위에 따르면 총 4개의 경우의 수가 나오며 블로킹-비동기, 논블로킹-동기에 대한 예시(polling)가 있긴 하지만 블로킹/동기..

하드웨어 레벨 해당 섹션은 키보드의 물리적인 동작과 그에 따른 운영체제의 인터럽트에 대해 다룹니다. "g"가 눌렸을 때 가장 먼저 google의 "g"를 입력하게 되면 해당 입력 이벤트가 브라우저에 전달되고 자동 완성 기능이 실행됩니다. 사용 중인 브라우저의 알고리즘과 개인/익명 모드를 사용하는지 등에 따라 다양한 URL이 URL 창 아래의 드랍박스 형태로 나타납니다. 대부분의 알고리즘은 검색 기록, 즐겨찾기, 쿠키, 빅데이터 기반의 유명한 검색어 등을 이용하여 정렬하여 나타냅니다. "google.com"의 단어를 하나 하나 입력해갈 때마다 알고리즘은 수정되며 추천 URL이 변경될 것이며 "google.com" 입력을 전부 끝내기도 전에 알고리즘에 의해 "google.com"이 추천될 수도 있습니다. "..

hashtable을 이용하면 해당 값에 접근하는 시간이 O(1)으로 일정한데 반해 b-tree를 이용한다면 O(logn)으로 압도적인 성능 차이를 보인다. 얼핏 생각하기에 hashtable로 구현한다면 훨씬 빠를 것같은데 왜 대부분의 DB의 인덱싱은 b-tree로 구현되어 있는걸까? 해시테이블 장점 특정한 값에 대해 O(1)의 시간으로 접근할 수 있다 insert와 delete 시에 인덱싱 관리가 효율적이다 구현하기 쉬움 단점 정렬이 효율적이지 못 하다 데이터 전체 크기가 커지면 커질수록 해시 충돌 문제에 의해 효율이 떨어진다 B-tree 장점 예상 가능한 순서로 순회를 한다 (작은 값에서 큰 값으로 혹은 큰 값에서 작은 값으로) 제한 조건이 걸린 조회에서 효율적이다 (e.g. 'abc'로 시작하는 모든..

결론 결론부터 말하자면 그냥 자바에서 String을 Immutable로 만드는 것이 더 좋다고 판단하였기 때문에 Immutable인 것이다. 그래서 질문을 바꿔 다시 물어봐야 한다. 왜 자바의 디자이너는 String을 Immutable로 설계하였을까? 디자인적인 측면 자바에서는 특별한 존재인 String을 String Constant Pool이라고 불리는 리터럴 String을 보관하는 영역이 heap에 따로 존재한다. String이 기본 객체 중 가장 많이, 자주 사용되기 때문에 객체를 생성하고 제거하는데 드는 오버헤드를 최소화하기 위해 String만을 위한 특별한 메모리 구역을 heap 영역에 만들어두고 이를 HashMap 형태로 관리한다. (String Constant Pool은 HashMap으로 구..

자바에서 객체가 같은지 비교하기 위해 equals()와 hashCode()를 오버라이딩하여 사용한다. 동작 원리를 알아보고 왜 오버라이딩이 필요한지 알아보자. 오버라이딩 되지 않은 equals() public boolean equals(Object obj) { return (this == obj); } 오버라이딩하지 않은 Object의 equals()는 단순하게 객체의 주소값만을 비교해서 주소가 같으면 true 아니면 false를 반환한다. ==와 똑같이 동작한다. String의 equals() String의 equals는 다르게 동작한다. 자바에서 String은 항상 특별취급받는 존재이다! String의 equals는 다음과 같다. 주소를 비교해서 같으면 true. charArray를 비교해가면서 다를..

용어 물리적 코어 : 물리적으로 존재하는 리소스로 연산을 하는 주체. 스레드 : 물리적인 개념에서 말하는 스레드는 인텔의 Hyperthreading이나 AMD의 SMT를 이용하여 물리적인 개념의 코어를 스레드의 개수만큼 곱해서 OS에게 그만큼의 논리적 코어를 이용할 수 있게 하는 개념. e.g. 8코어가 존재하고 코어마다 2스레드라면 8코어 16스레드가 되고 OS는 16개의 코어로 인식. 논리적 프로세스 : 한 개 혹은 그 이상의 스레드에 의해 실행되고 있는 프로그램의 인스턴스를 프로세스라 한다. 스레드 : 프로세스 내에서 실질적인 연산을 하는 작업의 단위를 말한다. 컨텍스트 : 프로세스가 CPU에 의해 실행될 수 있는 모든 현재의 정보의 집합을 컨텍스트라 한다. 일종의 메타데이터라 볼 수 있다. 컨텍스..

프레임워크의 내부 구현체를 공부하다 보면 심심치 않게 나오는 단어가 Reflection이었고 많은 사람들이 리플렉션이 느리다고 하지만 딱히 속시원하게 설명해주는 글이 없어 따로 공부해보았다. 리플렉션이란 리플렉션은 런타임에 결정될 클래스 타입을 컴파일 시에 결정한 것처럼 행동할 수 있게 하는 API이다. 어떤 클래스가 들어오든 미리 리플렉션 해둔 클래스처럼 행동하게 만들 수 있다는 것이다. 다만 클래스 타입은 동적으로 그때 그때마다 결정된다. 리플렉션은 일종의 desired state를 명시하는 것이다. 이 말만 들으면 마치 리플렉션이 Silver Bullet인 것처럼 느껴지지만 당연하게도 프로그래밍에 은탄환은 존재하지 않는다. 리플렉션의 단점을 알아보자. 단점 성능 상의 가장 큰 문제점은 컴파일러 최적..

기존의 빌드 이후 실행되던 쉘스크립트는 빌드와 실행 자체는 잘 되지만 기존에 존재하던 이미지와 컨테이너를 삭제하지 못 하고 계속해서 증식하던 문제가 발생했다. 기존 쉘스크립트는 올릴 필요가 없을 정도로 완벽하게 깔끔한 정답을 찾아서 공유한다! 쉘스크립트 cd ~/deploy docker-compose pull docker-compose up -d --remove-orphans yes | docker image prune 1. docker-compose.yml이 존재하는 폴더의 위치로 이동하고 2. 이미지를 새로 받아온다 3. 컨테이너를 재시작한다. 어디에도 연결되지 않은 컨테이너는 여기서 삭제된다. 4. yes | docker image prune은 사용되고 있지 않은 이미지를 삭제하는 과정인데 꼭 필요..

도커로 nginx를 설정해주는 방법은 크게 2가지 단계로 볼 수 있다. 1. nginx의 설정파일인 /etc/nginx/nginx.conf 수정하기 2. docker-compose.yml 작성 후 up 하기 nginx.conf 작성 /etc/nginx/nginx.conf 는 위치와 파일명이 정해져있는 값으로 디폴트로 파일이 주어지지만 크게 의미있는 내용은 존재하지 않아 아예 다른 곳에 nginx.conf 파일을 새로 작성해서 container가 올라갈때 mount해주는 것이 편하다. 마운트될 nginx.conf는 어떤 위치에 작성해도 상관없으나 docker-compose.yml과 같은 디렉토리 혹은 그 밑에 있는 것이 관리측면에서 더 편할 것이라 생각하여 deploy 내에 docker-compose.ym..

프로젝트를 얼추 완성하고나서부터 빌드, 배포에 대해서 공부를 하기 시작했다. 한번에 홈서버, 네트워크, 리눅스, 환경변수, 도커, 빌드, 배포, 젠킨스, 도커 안의 도커 등의 개념을 공부하다 보니 많은 점들이 한꺼번에 주입되어 너무 헷갈렸기에 그 헷갈렸던 점들을 정리해놓고자 한다. 관심사의 분리가 이렇게 중요하구나라는 것을 깨닫게 된 좋은 계기였다. 빌드 빌드의 주체는 Gradle, Maven, Ant와 같은 빌드툴이다. 개념적으로는 알고 있었지만 젠킨스 도커 등을 공부하면서 마치 이런 툴들이 빌드까지 대신 해주는 것처럼 느껴졌다. 젠킨스가 빌드를 해주는 것이 아닌 젠킨스의 파이프라인에 빌드 단계가 들어가 빌드툴 plugin이 빌드를 한다는 개념을 정확히 잡아야 한다. 배포 배포는 AWS나 홈서버가 하는..