다음 글은 Real MySQL 스터디를 진행하면서 정리한 4.1장 내용입니다. 🙌 💡 Intro 프로젝트를 진행해보니 서비스의 대부분의 병목은 데이터베이스에서 발생한다는 것을 알 수 있었다. DBA가 아니더라도 기본적으로 파생된 쿼리가 어느 과정을 거쳐서 처리되는지, 성능을 좌우하는 시스템 변수들은 어떠한 것들이 있는지 아는 것이 매우 중요하다고 생각한다. MySQL 엔진은 데이터베이스의 뇌의 역할을 한다. 기본적은 서버 구조와 MySQL 엔진과 스토리지 엔진의 차이점 및 담당 부분을 이해해보자. 🌩 MySQL 서버의 구조 머리 역할을 하는 MySQL 엔진과 손발 역할을 하는 스토리지 엔진(InnoDB, MyISAM)이 있다. 스토리지 엔진은 핸들러 API를 만족하면 직접 구현하여 추가해서 사용할 수 있다. 🌩 MySQL 엔진 아키텍쳐 MySQL 전체구조 MySQL 엔진 먼저 MySQL 서버는 대부분의 상용 언어에서 지원할 수 있으며 MySQL 서버의 커넥션 핸들러에서 커넥션을 관…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 11] equals를 재정의하려거든 hashCode도 재정의하라 와 함께 도 재정의하지 않으면 이나 의 원소로 사용할 때 일관성이 무너진다. Object 명세에 따르면 다음 규약이 있다. eqauls(Object)가 두 객체를 같다고 판단하면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. 다시 말해서 논리적으로 같은 객체는 같은 해시코드를 반환해야 한다는 것이다. 해시코드가 같지 않으면 다음 코드에서 일관성이 깨진다. 좋은 hashCode를 작성하기 hashCode의 로컬 int 변수 result를 첫번째 핵심 필드의 해시코드로 초기화 한다. (여기서 해시코드는 다음 2.a 단계대로 계산한다.) 다음 핵심 필드 들에 대해서 다음과 같이 해시코드를 계산하고 result 필드를 갱신한다. 기본 타입 필드라면 Type.hashCode(f)를 수행한다. Type은 해당 기본 타입의 박싱 클…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 9] try-finally 보다는 try-with-resources를 사용하라 자바에서 close 메서드를 직접 호출해서 닫아주어야하는 자원들 , , 등등 try-finally 사용시 단점 try-finally를 사용한다면 닫아야 하는 자원이 많아질수록 매우 복잡해진다. try 블록과 finally 블록에서 모두 예외가 발생할 수 있는데, 만일 둘다 예외가 발생했을 경우 이후에 일어난 예외가 첫번째 예외를 삼켜서 디버깅을 어렵게 한다. try-with-resources로 해결 짧고 간결하여 읽기가 수월하다. try 내부와 에서 모두 예외가 발생 하더라도 첫번째 예외만 보여지고 두번째 예외는 되어 출력된다. catch 블록을 함께 사용하여 여러 예외를 처리할 수 있다. 🌩 [아이템 10] equals는 일반 규약을 지켜 재정의하라 대부분은 를 재정의 하지 않는 것이 가장 좋다. 책에서는 특히나…

이 글은 몇몇 크루들과 이펙티브 자바 스터디를 하며 정리한 내용입니다. 🙌 🌩 [아이템 7] 다 쓴 객체 참조를 해제하라 JVM 언어를 사용한다면 GC가 알아서 사용되지 않는 객체를 해제할텐데 왜 이런 항목이 있는걸까? 다음과 같은 경우에는 GC가 해당 객체가 다 쓴 객체인지 아닌지 판단할 수가 없다. Stack 자료구조를 구현한 예시이다. 다음과 같은 경우 다시 참조되지 않을 객체에 대한 해제가 이루어지지 않았기 때문에 ‘메모리 누수’가 발생한다. 이 프로그램이 오랜시간 실행이 되다보면 메모리 사용량이 늘어나 성능이 저하되거나 심하면 를 일으킬수도 있다. 위 코드와 같은 경우 배열에 더이상 사용되지 않는 영역의 객체 참조를 배열이 여전히 가지고 있다. 예를 들면 바깥에 존재하는 객체들에 대해서 말이다. 이렇게 GC에게 객체 처리를 맡기는 언어에서 이러한 메모리 누수를 찾기가 매우 어렵다. 또한 쓰이지 않지만 참조되고 있는 객체의 영향이 해당 객체에서 끝이 나는 것이 아니라 해…