Language 썸네일형 리스트형 [이펙티브 자바][아이템 9] try-finally 보다 try-with-resources 를 사용하라 - 컴도리돌이 많은 개발자들이 자주 사용하는 try-finally 블록은 리소스를 명시적으로 해제해야 하는 경우에 자주 사용됐지만, 이 방법에는 몇 가지 단점이 있어요. 코드가 장황해지고, 가독성이 떨어지며, 예외가 발생할 경우 자칫 리소스 해제가 제대로 이루어지지 않을 가능성이 생기죠. 특히 스프링 부트 환경에서 여러 외부 리소스나 파일, 데이터베이스 연결 등을 다룰 때 더욱 신중하게 할 필요가 있습니다. 🧐 이런 문제를 해결하기 위해 등장한 것이 try-with-resources인데, 이 구조는 자바 7에서 도입되었고, 자동으로 리소스를 해제해 주는 것이 특징이에요. 리소스를 명시적으로 닫지 않아도 되기 때문에 코드가 훨씬 간결해지고, 예외가 발생하더라도 안정하게 리소스를 관리할 수 있죠. Connection .. 더보기 [이펙티브 자바][아이템 8] finalizer와 cleaner 사용을 피하라 - 컴도리돌이 이번 주제는 저에게는 매우 생소한 주제였어요 😓finalizer와 cleaner 같은 개념이 매우 생소하였거든요, 저는 보통 try-with-resources 구문과 @PreDestroy 어노테이션을 사용해서 자바에서 객체가 더 이상 필요하지 않을 때 리소스를 정리하곤 했는데, 객체 생성 자체를 워낙 많이 하지 않는 편이어서 더욱 생소했던 거 같네요. 그래도 열심히 책을 읽었기에, 오늘 이 주제로 글을 남기려고 합니다. 😤 과거에는 자바에서 객체가 더 이상 필요하지 않을 때 리소스를 정기하기 위해 finalizer를 사용했습니다. 하지만 finalizer는 다음과 같은 문제가 있었죠.첫 번째는 finalizer는 언제 실행될지 예측할 수 없다고 합니다. 이거 매우 위험하지 않나요? 실행 시점이 정확히.. 더보기 [이펙티브 자바][아이템 7] 다 쓴 객체 참조를 해제해라 - 컴도리돌이 자바 프로그래밍을 하다 보면 한 번쯤은 "메모리 누수"라는 문제를 들어본 적이 있을 거예요. 그렇다면 메모리 누수가 실제로 어떻게 발생할까요? 자바는 가비지 컬렉터(Garbage Collector, GC)를 통해 사용하지 않는 객체를 자동으로 수거하는데, 그렇다면 왜 우리는 여전히 메모리 누수를 걱정해야 할까요?? 🤔 가비지 컬렉터가 잘못된 객체를 수거하지 못하게 만드는 주된 이유 중 하나는 바로 다 쓴 객체에 대한 참조를 해제하지 않기 때문이에요. 이 문제는 특히 메모리를 장시간 사용하거나, 많은 객체를 다루는 애플리케이션에서 더 심각하게 드러난다고 합니다. 가령, 우리가 다 쓴 객체를 필요 이상으로 참조하고 있는 경우, 해당 객체는 가비지 컬렉터의 대상이 되지 않으며, 그 결과 메모리가 불필요하게 .. 더보기 [이팩티브 자바][아이템 6] 불필요한 객체 생성을 피하라 - 컴도리돌이 자바를 사용하면서 이 객체를 매번 새로 만들어야 할까?라는 상황이 수 없이 오게 됩니다. 저 또한 이런 물음을 스스로에게 던져본 적이 매우 많았죠.. 이펙티브 자바에서 강조하는 불필요한 객체 생성을 피하라 는 원칙이 바로 저 물음에서 시작돼요. 그렇다면 왜 불필요한 객체 생성을 피하는 것이 중요할까요? 🙄 자바에서 객체를 생성하는 건 매우 흔한 일이죠. new 키워드로 쉽게 객체를 만들 수 있으니, 별 다른 고민 없이 계속해서 객체를 생성할 수 있죠. 하지만 반복적인 객체 생성이 메모리와 성능에 어떤 영향을 미칠까요? 🤔객체를 생성하는 과정은 메모리 할당, 초기화, 그리고 생성자 호출 등의 작업을 수반해요. 이러한 작업들이 단일 객체에 대해서는 큰 문제가 되지 않을 수 있지만, 동일한 객체를 반적으로.. 더보기 [이펙티브 자바][아이템 5] 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 - 컴도리돌이 자원을 직접 생성하거나 관리하는 방식은 코드의 유연성과 유지보수성을 크게 제한할 수 있습니다. 자원을 직접 관리하고 명시하는 방식이 실제로는 많은 문제를 초래할 수 있다고 합니다. 왜 그럴까요? 🤔 자원을 직접 명시하는 경우, 예를 들어 파일 읽기와 같은 작업을 수행하는 유틸리티 클래스를 작성한다고 가정해 볼게요.파일을 읽기 위해 BufferedReader를 직접 생성하는 클래스 FileReaderUtil을 만들었다고 생각해 보면, 클래스 내부에서 직접 BufferedReader를 생성하고 관리하는 코드가 들어가죠. 이렇게 되면, 이 클래스는 파일 시스템과 강하게 결합되게 됩니다. 즉, 파일 경로와 파일을 여는 방식이 하드코딩되어 있어, 만약 파일 경로를 바꾸거나 다른 파일 시스템 접근 방식을 사용해야.. 더보기 [이펙티브 자바][아이템 4] 인스턴스화를 막으려거든 private 생성자를 사용하라 - 컴도리돌이 클래스를 만들 때 모든 메서드가 인스턴스화되어야 할까요? 🤔때때로 우리는 클래스의 인스턴스가 만들어지는 것을 막아야 할 필요가 있어요. 예를 들어, 유틸리티 클래스를 만들거나, 특정 메서드나 상수를 집합적으로 관리하고 싶을 때, 불필요한 인스턴스를 방지하는 것이 중요할 수 있습니다. 그럼 어떻게 해야 할까요? 자바에서는 인스턴스화를 막는 가장 쉬운 방법 중 하나는 private 생성자를 사용하는 것입니다. 이것은 클래스의 인스턴스가 외부에서 생성되지 않도록 보장을 하기 때문이죠. 쉽게 생각하면, 비밀번호로 잠긴 문이 있다고 가정하면, 비밀번호를 모르면 문을 열 수 없듯이, private 생성자를 사용하면 외부에서 인스턴스를 생성할 수 없게 됩니다. 자주 사용하는 유틸리티 메서드를 모아둔 클래스를 만들.. 더보기 [이펙티브 자바][아이템 3] private 생성자나 열거타입으로 싱글턴임을 보증하라 - 컴도리돌이 싱글턴 패턴은 일반적으로 자원의 효율적인 사용과 프로그램의 일관성을 유지하기 위해 사용돼요. 예를 들어, 애플리케이션에서 로깅, 캐시, 설정 정보와 같은 클래스는 인스턴스가 여러 개일 필요가 있을까요?? 당연히 없겠죠? 만약 이런 클래스의 인스턴스가 여러 개라면 상태가 서로 달라질 수 있고, 이는 예기치 않은 버그를 유발할 수 있어요 😔그렇기 때문에 이런 클래스를 싱글톤으로 구현하여, 프로그램 내에서 단 하나의 인스턴스만 존재하도록 하는 것이 중요합니다. 🛠️ private 생성자와 싱글톤 보증자바에서는 싱글톤 패턴을 구현할 때 가장 많이 사용되는 방법 중 하나는 private 생성자를 활용하는 것입니다. 이 방식은 클래스의 인스턴스를 외부에서 생성할 수 없도로 막아줘요.public class Sin.. 더보기 [이펙티브 자바][아이템 2] 생성자에 매개변수가 많을 때는 빌더를 고려하라 - 컴도리돌이 개발을 하다 보면 객체를 생성해야 할 때가 당연히 있습니다. 그런데 그 객체를 생성하기 위해 생성자를 사용했는데, 매개변수가 한두 개가 아니라 다섯 개, 여섯 개, 열 개가 넘어갈 때가 있지 않나요? 🤔 예를 들어 영양 정보를 담는 NutritionFacts 클래스를 가지고 가정해 볼까요? public class NutritionFacts { private final int servingSize; // 필수 private final int servings; // 필수 private final int calories; // 선택 private final int fat; // 선택 private final int sodium; // 선.. 더보기 이전 1 2 3 4 ··· 27 다음
