하드웨어 레벨 해당 섹션은 키보드의 물리적인 동작과 그에 따른 운영체제의 인터럽트에 대해 다룹니다. "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'로 시작하는 모든..
Spring MVC는 다른 대부분의 MVC 패턴이 그러하듯 디자인 패턴 중 Front controller pattern을 적용하여 구현되어 있다. Front controller pattern은 한 요청이 들어오면 그 요청에 대한 응답을 할때까지 필요한 작업의 모든 것을 관장하는 역할을 하는 controller를 메인으로 두고 작업을 처리하는 패턴이다. '요청이 들어오면 응답이 나갈 때까지 작업이 진행된다'를 들으면 바로 떠오르는 단어가 하나 있을 것이다. Blocking IO. Spring MVC는 Blocking IO로 동작한다. 그렇기 때문에 각 요청마다 요청을 처리해줄 스레드를 만드는 것이고 이 처리를 좀 더 효과적으로 하기 위해 Thread Pool이 필요하게 되었고 IO heavy한 아키텍처에서..
결론 결론부터 말하자면 그냥 자바에서 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에 의해 실행될 수 있는 모든 현재의 정보의 집합을 컨텍스트라 한다. 일종의 메타데이터라 볼 수 있다. 컨텍스..
5월부터 진행해온 1인 개발로 3개월 가량 진행해온 쇼핑몰 프로젝트의 마무리가 되어감에 따라 프로젝트 동안 겪었던 내용과 감정들을 정리해놓고자 합니다. 프로젝트에 대한 세부 내용은 깃허브의 README로 대체합니다. 프로젝트 시작 이유 및 선택 2달의 기간 동안 동영상이나 책을 통해 이론으로만 공부하다 보니 머리 속의 지식들이 workflow 형태로 정리되는 것이 아닌 파편적으로 퍼져있다고 느껴졌다. 예를 들어 어떤 기능을 만든다고 생각하고 머리 속으로 쭉 흐름을 따라가다 보면 계속 군데 군데 내용이 '기억나지 않아서' 코드를 작성하지 못 하는 것이다. 기억이 나지 않는다는 것은 해당 내용을 이해한 것이 아니라 외운 것에 불과하다는 의미였으므로 이 문제를 해결할 방법이 필요했다. 백견이불여일타라는 프로그..
Slf4j는 Simple Logging Facade for Java의 acronym으로 파사드 패턴을 이용한 로깅 인터페이스라는 의미 정도로 해석할 수 있을 것이다. Slf4j라는 파사드 인터페이스를 앞에 세워두고 Application과 로깅 프레임워크간의 직접적인 결합도를 없애고 파사드 하나만을 바라보게 해서 로깅 구현체가 어떤 식으로 변경되든 변화를 무시 혹은 최소화할 수 있다. System.out.println을 지양해야 하는 이유 성능을 떠나서 System.out.println는 콘솔창(표준 출력)으로 결과를 남기지만 로깅이 의미를 가지려면 파일의 형태로 저장이 되어야 하므로 로깅의 개념으로 사용이 불가능하다. (방법이야 찾아보면 가능하겠지만 성능의 오버헤드를 생각하면..) System.out.p..
프레임워크의 내부 구현체를 공부하다 보면 심심치 않게 나오는 단어가 Reflection이었고 많은 사람들이 리플렉션이 느리다고 하지만 딱히 속시원하게 설명해주는 글이 없어 따로 공부해보았다. 리플렉션이란 리플렉션은 런타임에 결정될 클래스 타입을 컴파일 시에 결정한 것처럼 행동할 수 있게 하는 API이다. 어떤 클래스가 들어오든 미리 리플렉션 해둔 클래스처럼 행동하게 만들 수 있다는 것이다. 다만 클래스 타입은 동적으로 그때 그때마다 결정된다. 리플렉션은 일종의 desired state를 명시하는 것이다. 이 말만 들으면 마치 리플렉션이 Silver Bullet인 것처럼 느껴지지만 당연하게도 프로그래밍에 은탄환은 존재하지 않는다. 리플렉션의 단점을 알아보자. 단점 성능 상의 가장 큰 문제점은 컴파일러 최적..
스웨거2를 이용하여 문서화를 진행하던 도중 API별로 깔끔하게 모아서 정리하고 싶었으나 아래와 같이 @Api 어노테이션의 description이 deprecated되어 사용할 수 없는 문제가 발생했다. @Api(tags = "tag", description = "태그") //deprecated public class MyApiController { 해당 문제에 대해 찾아보니 이미 2015년 부터 해당 issue가 있었고 2019년도까지는 deprecated된 속성을 계속 써왔던걸로 보인다. 원인 해당 문제에 대한 원인은 Swagger 1.X 버전에서는 @Api의 description 속성을 통해 그룹화했었지만 Swagger 2.X 버전에서 tags라는 속성을 통해 그룹화를 하게 되며 해당 어노테이션간의 ..
- Total
- Today
- Yesterday
- ModelAttribute
- RequestPart
- RequestParam
- IDE
- 도커
- vim
- JavaScript
- RequestBody
- lunarvim
- 아키텍처
- 배포
- neovim
- 루나빔
- 레디스
- Dap
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |