기록들 https://github.com/ndgndg91

개요 현재 개발자 채용시장에 있어서 Java 가 가장 영향력있는 언어이지 않을까 생각한다. Java 가 영향력이 큰 이유는 아마도 ecosystem 덕분이지 않을까 생각이 든다. 최근에 여러 모던 언어들이 등장하고 있지만, 여전히 Java 에 입지는 굉장히 강력하다. 물론 Kotlin 이라는 언어가 등장하면서 판도의 흐름이 보이고 있다. 둘의 공통점은 JVM 기반 언어라는 점이다. (물론 Kotlin/JS 는 다른이야기 이지만) 이외에도 Scala, Clojure, Groovy 등등 JVM 기반 언어들이 많다. 이번글에서는 JVM 을 high-level 구조를 정리해보려고 한다. 해당 구조는 Java 8 을 기준으로 정리를 했다. 현재 LTS 로 Java 17 까지 출시가 되었으며 변경사항이 있는 것을 참고해야 한다. JVM 구조 ClassLoader Subsystem JVM 언어의 철학 중 하나가 Write Once Run Anywhere 이다. compile 시 하드웨어가 바로 이해할 수 있는 low-level 로 번역이 되는 것이 아닌 JVM 이 이해할 수 있는 byte code 로 변환된다. 바로 class 파일 포맷이다. ClassLoader 의 역할이 바로 compile 된 class 파일들을 runtime 에 동적으로 load 하는 역할을 한다. ClassLoader 로 인해서 runtime system 은 machine 의 file 및 filesystem 을 알 필요가 없다. 모든 class 파일은 한번에 load 되는 것이 아니다. 필요한 시기에 필요한 class 파일을 요청하며 이에따라 요청받은 ClassLoader 가 역할을 한다. 또한 ClassLoader 는 하나가 아니다. 요청한 class path 나 type 에 따라 동적으로 ClassLoader 가 선택된다. ClassLoader 는 3가지 종류가 있다. - Bootstrap ClassLoader : java class 가 아닌 c/c++ 로 이루어져있다. JDK interna...

이번글에서는 JDBC API Statement 와 PreparedStatement 의 차이점에 대해서 정리하려고한다. Java Database Connectivity API 는 Java 를 사용하여 data access 를 할 수 있도록 제공해준다. RDBMS 뿐만 아니라 spreadsheets 와 flat files 도 가능하다. JDBC API 는 2개의 패키지로 구성된다. - java.sql - javax.sql Statement String-based query 를 실행시킨다. parameter 대신 static SQL 을 처리하기 좋다. runtime 에 오직 한 번만 실행시킬 DDL 을 사용하기 적합하다. Binary Data Read / Write 작업에 사용이 불가능하다. Binary Protocol 이 사용되지 않는다. SQL Injection 에 취약하다. PreparedStatement parameterized query 를 기반으로 한다. runtime 에 parameter 를 다루고 여러번 수행되는 어떤 종류의 Query 도 처리하기 좋다. Dynamic query 를 처리하기 좋다. Binary Data Read / Write 작업이 가능하다. Binary Protocol 사용이 가능하다. 둘의 가장 큰 차이점은 precompiled 에 따른 성능과 보안 측면에서 SQL injection 방지이다. 참조 https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/ https://www.baeldung.com/java-statement-preparedstatement https://www.geeksforgeeks.org/difference-between-statement-and-preparedstatement/ https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html#:~:text=As%20a%20result%2C%20the%20...

개요  Spring Framework 를 사용할 때 AOP 는 필수라고 말해도 과언이 아니다. Logging, Transaction Management, Caching, Security 등등 에서 주로 사용된다. 그렇다면 Spring AOP 는 어떻게 동작할까? 이번 글에서 정리를 해보려고 한다.  Spring 에서 AOP 는 JDK Dynamic Proxy 혹은 CGLIB Dynamic Proxy 를 사용하여 Proxy 를 생성하여 관리한다.  Proxy target object 가 하나 이상의 interface 를 구현하는 경우에는 JDK Dynamic Proxy 가 사용된다. 반대로 target object 가 interface 를 구현하지 않는다면 CGLIB proxy 가 생성된다. 하지만 proxy-target-class=true 로 설정한다면 interface 를 구현하더라도 CGLIB proxy 가 사용된다. CGLIB Proxy 를 사용할 때 고려해야 할 몇가지가 있다. - final method 는 overriding 이 불가능하기 때문에 advice 적용이 불가능하다.  - target class 가 final 일 경우 불가능하다. - Spring 3.2 version 전의 경우 CGLIB 와 관련된 jar 를 classpath 에 추가해주어야 한다. 3.2 version 부터는 org.springframework.cglib 로 repackaged 되어 spring-core jar 안에 포함이 되었다. - Spring 4.0 version 전의 경우 proxy target object 의 생성자는 두 번 호출되었다. 또한 기본 생성자가 필수였다. 4.0 version 이후부터는 Objenesis 를 통해서 proxy instance 가 생성될 때 더이상 생성자가 두 번 호출되지 않게 되었다. 일반적이지 않은 경우이지만 4.0 version 전에서는 proxy target object 의 생성자에 주요한 로직을...

이번 글에서는 System Call 과 I/O 에 대한 기본적인 개념을 정리하려고 한다. System Call? 프로그램이 실행되는 OS 의 커널에게 요청하는 프로그래밍 방식이라고 정의할 수 있다. 하드 디스크 드라이브 또는 카메라 등 하드웨어와 관련된 요청일 수 도 있고, 새로운 프로세스를 생성하거나 실행에 대한 요청일 수 도 있고, 프로세스 스케쥴링과 같은 요청일 수 있다. 즉, 프로세스가 해당 OS 의 커널 서비스를 사용하는 것을 시스템 콜이라고 한다. System call 의 종류는 어떤것이 있을까? 크게 6가지로 정리할 수 있다. 1. Process Control     - create process     - terminate process     - load, execute     - get/set process attributes     - wait for time, wait event, signal event     - allocate and free memory     Java 를 기준으로 간단한  예시를 작성해보았다. ProcessBuilder 를 통해서 ls shell command 를 새로운 process 를 생성하여 실행하고 main process id 와 새로 생성한 process id 를 출력하고 process 를 종료하는 코드이다. 이과정에서        이외에도 현재 살아있는 모든 process 에 대한 정보를 비동기로 가져와서 출력한다. 2. File management     - create file, delete file     - open, close     - read, write, reposition     - get/set file attributes Java 통해서 간...

 Race Condition 즉 동시성 문제는 하나의 트랜잭션이 다른 트랜잭션에서 동시에 변경한 데이터를 읽거나 두 트랜잭션이 동시에 같은 데이터를 변경하고자 할 때 나타난다. 동시성 문제로 발생하는 버그는 타이밍에 운이 없을 때 발생하기 때문에 일반적인 테스트로 발견하기 어렵고, 타이밍 이슈는 간할적으로 발생할 수 있으며 해당 이슈를 재현하기 힘들고 추론도 힘들다. 어플리케이션 개발은 한 번에 한 사용자를 가정하고 개발하기도 어려운데 동시 사용자가 많다면 당연히 더 어렵다. 하지만 현실세계에서 동시성이 없는 어플리케이션이 없다고 봐도 무방할 만큼 동시성을 고려하지 않을 수 없다. 재고가 얼마 남지 않은 상품을 동시에 여러 구매자가 구매할 때, 하나의 회의실을 서로가 먼저 예약하려고 할 때, BTS 콘서트 티켓을 예매할 때.. 등등 Optimistic Concurrency Control 우리나라말로 해석하면 "낙관적 동시성 제어" 이다. 무엇이 낙관적일까? 위험한 상황이 발생할 가능성이 있을 때 Transaction 을 막는 대신 모든것이 괜찮아질 것이라고 희망을 갖고 계속 진행한다는 의미이다. 여기서 위험한 상황이란 다른 Transaction 이 현재 진행 중인 Transaction 이 변경하려고 하는 데이터와 동일한 데이터를 변경하고자 하는 상황을 의미한다. 그리고 막는다는 표현은 Database 관점에서 Exclusive Lock 을 통해서 Transaction 이 순서로 진행되는 것을 의미한다. 막지 않는 대신 각각의 Transaction 은 Commit 전에 Transaction 내에서 읽었던 Data 가 변경되지 않은것을 확인한다. 이는 이른바 MVCC(Multi Version Concurrency Control) 기법을 통해서 이루어진다. 만약 Data 의 변경이 감지된다면 해당 Transaction 은 Rollback 하고 재시작을 한다. Pessimistic Concurrency Control 낙관적의 반대인 비관적이라는 말은...