부트캠프 67일차 후기

오늘도 면접문제를 준비하였다.

 

가장 기억에 남는 것은 Java가 컴파일되는 과정을 배운 것이다.

Java가 컴파일 되는 과정은 간결하게 다음과 같다.

 

1. 개발자가 자바 소스코드(.java)를 작성한다.
2. java 코드를 java compiler가 바이트코드로 바꿔서 .class파일을 생성한다.
3. 컴파일 된 바이트코드를 JVM의 클래스로더에게 전달한다.
4. 클래스 로더는 동적 로딩을 통해 필요한 클래스들을 로딩 및 링크하여 런타임 영역, 즉 JVM의 메모리에 올린다.
5. 실행 엔진은 JVM 메모리에 올라온 바이트 코드들을 명령어 단위로 하나씩 가져와서 실행한다.

 

실행 엔진의 방식은 2가지가 존재한다.
- 인터프리터: 바이트코드 명령어를 하나씩 읽어서 해석하고 실행한다. 하나하나의 실행은 빠르나, 전체적인 실행속도는 느리다는 단점이 있다.
- JIT(Just In Time) 컴파일러: 바이트코드 전체를 컴파일하여 바이너리 코드로 변경하고 실행한다. 실행속도는 인터프리터보다 빠르다.
JVM은 기본적으로 인터프리터 방식을 사용하지만, 특정 메서드가 자주 수행되면 JIT 컴파일러 방식을 사용한다.

 

이전에 Java는 Call By Reference를 지원하지 않는다고 들었었는데, 이번에 정확히 알게 되었다. 정확히 말하자면 C++처럼 원시형을 위한 Call By Reference를 지원하지 않는 것이고, Class나 Array 같은 복사를 하기 부담스러운 구조는 Call By Reference를 지원한다. 정확히는 Call By Reference가 아닌 Call By Address로 부른다 하지만, 거기서 거기인것 같다.

 

또, 쿼리 최적화 방법을 배웠는데, 나중에 사용해도 유익할 것 같다.

 

- SELECT * 사용 금지: 필요한 칼럼만 조회한다.
- LIKE 사용 시 와일드카드 문자열(%)을 String 앞부분에 배치하지 않기: 모든 Cell을 탐색하고 수식을 걸어서 조건 탐색 여부를 판단하기 때문.
- 조건을 부여할 때 별도의 연산을 걸지 않는 것이 좋음: 위의 이유와 동일
- SELECT DISTINCT, UNION DISTINCT와 같은 중복 값 제거 연산은 최대한 사용 금지: 대신 EXISTS를 활용하는 방법을 추천
- 서브 쿼리에서 ORDER BY 사용하지 않기: 서브 쿼리에서 사용 시 많은 비용 발생
- 3개 이상의 테이블을 Inner Join 할 때는 크기가 가장 큰 테이블을 from 절에 배치하고, 남은 테이블을 작은 순서대로 배치: 항상 통용되지는 않음
- GROUP BY 연산시에는 HAVING 보단 WHERE 절을 사용하는 것이 더 낫다: WHERE 절이 HAVInG 절보다 먼저 실행되어서 미리 데이터 크기를 줄일 수 있음

 

이어서 DB 로직을 최소화하는 법을 알게 되었다.

 

- 자주 사용하는 데이터를 메모리에 캐싱한다.
- 쿼리 성능 향상을 위해 쿼리를 최적화하거나 인덱스를 사용한다
- 대량의 데이터 작업을 처리할 때는 실시간이 아닌 배치 처리 작업을 고려한다.
- 장기 실행되는 쿼리나 작업은 타임아웃이나 데드라인을 설정한다
- 때때론 비정규화가 데이터 검색을 빠르게 만들 수 있다
- 트랜잭션을 필요한 경우만 사용하고, 긴 트랜잭션을 피하고, 격리 수준을 적절히 설정한다
- 자주 사용하는 쿼리 결과를 캐싱한다.

 

그 외 여러가지가 있다.

 

내일은 면접문제를 다 정리하자. 그리고 시간이 되면 포트폴리오를 좀 정리해보자