Java의 ForkJoinPool로 알아보는 Work-Stealing 동시성 모델이번 포스팅에서는 Java의 동시성 처리를 위한 ForkJoinPool과 Work-Stealing 알고리즘에 대해 알아보겠습니다. Java 7부터 도입된 이 기능은 멀티코어 환경에서 효율적인 병렬 처리를 가능하게 해주는 중요한 도구입니다."ForkJoinPool은 병렬 스트림과 CompletableFuture가 사용하는 실행 메커니즘이자, 고성능 작업 분할을 위한 핵심 프레임워크입니다."- Doug Lea (Java의 java.util.concurrent 패키지의 주요 설계자)ForkJoinPool의 필요성일반적인 ThreadPool만으로는 다음과 같은 한계가 있습니다:작업 분배의 불균형: 일부 스레드에 작업이 집중되는 현상..

프로젝트의 시작 어느 날 익명의 기업으로부터 흥미로운 과제를 받았습니다. 과제의 내용은 다음과 같았습니다. 💡 회사는 스프린트 단위로 프로젝트를 진행합니다. 이번 스프린트에서는 사칙연산, 다음 스프린트에서는 삼각함수를 구현할 예정입니다. 추후에는 로그, 미적분이 예정되어 있습니다. 확장에 유리한 설계를 해주세요. v1. 설계의 시작과 문제점 인식 초기에 저는 사칙연산을 처리할 수 있는 간단하고 직관적인 설계를 구상했습니다. 이를 위해, 사용자의 입력을 분석하고 연산을 수행하는 Calculator 클래스와 연산을 추상화하는 Operation 인터페이스를 도입했습니다. 또한, 연산 종류에 따라 적절한 연산 객체를 생성하는 OperationFactory 클래스도 만들었습니다. 하지만 이 설계는 곧 두 가지 큰..

자바 개발자라면 누구나 효율적인 코드 구조와 객체지향적 설계의 중요성을 인식합니다. 특히, 게시물 추적 기능과 같이 데이터를 처리하고 분석해야 하는 경우, 코드의 재사용성과 확장성은 더욱 중요해집니다. 이 글에서는 DateBasedPostTracker 클래스를 예로 들어 정적 유틸리티 클래스와 인터페이스 기반 설계의 각각의 장단점을 탐구하고, 어떤 방법이 객체지향적인 설계 원칙, 특히 개방/폐쇄 원칙(OCP)을 더 잘 따르는지 논의해 보겠습니다. DateBasedPostTracker 클래스 소개 DateBasedPostTracker는 특정 날짜에 게시된 해축겔 게시판의 정보를 가져오는 기능을 제공하는 클래스입니다. 이 클래스는 세 가지 주요 기능을 포함합니다. 1. findFirstPage(String ..

최근 게시판 프로젝트로 끝까지 한번 해보자 라는 프로젝트를 진행하고 있던 와중,참 거슬리는 코드가 눈에 들어왔다.저게 틀린 코드라고 생각하지는 않았기에 저렇게 적었다만은,뭐랄까 참 지저분해 보이는 코드라서 리팩토링 욕구(?)가 솟았다. 그래서 어떻게 할까 고민을 하던 와중 먼저저 코드의 의미, 기능을 생각해보니 다음과 같았다. MemberUpdateDTO 의 Null 이 아닌 필드들만 DB에 업데이트 하기! 즉 필드의 null 체크를 좀 더 야무지게 할 수 있는 방법을 찾으면 됐다.그러다 Java 8 부터 도입된 Optional 을 사용하면 훨씬 더 안전하고,Java 표준 스펙에 의거한 코드를 만들 수 있지 않을 까 생각했다. 그래서 MemberUpdateDTO 의 null 이 올수 있는 필드를 Opti..

실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 인프런 | 강의스프링 부트와 JPA를 활용해서 API를 개발합니다. 그리고 JPA 극한의 성능 최적화 방법을 학습할 수 있습니다., 스프링 부트, 실무에서 잘 쓰고 싶다면? 복잡한 문제까지 해결하는 힘을 길러보세요www.inflearn.com영한갓님의 강의에서 회원의 정보를 수정하기 위해MemberService에 update 메서드를 추가하던 와중이었습니다."update 메서드는 엔티티를 바꾸겠다는 변경성 메서드인데, 이 메서드의 return type 을 Member로 한다면 update로 조회를 하는 꼴이 돼요.command와 query 가 같이 있는 꼴이 되죠.그래서 저는 update 메서드의 return type을 void로 하거..

1. 기본적으로 Object.equals() 는 Overriding 하지 않는 것이 정답이다.위 문장을 보고 이런 생각이 들었을 겁니다. "뭔 규약을 지켜 재정의하라면서, 애초에 하지 말라니?" 틀린 말은 아니다만, equals() 오버라이딩은 오류가 나기 쉬운 작업입니다. 그러기에 Equals 오버라이딩를 고민하고 있는 당신에게 만약 다음 상황들에 쳐해있다면 equals를 오버라이딩 하지 않는 것을 추천하지 않습니다!각 인스턴스가 고유하다. ex) Thread 클래스인스턴스의 '논리적 동치성' 을 검사할 일이 없다. ex) new Point(1,2), new Point(1,2)의 경우, 둘이 같다고 해석할 수도 있다.상위 클래스에서 재정의한 equals가 하위 클래스에서도 딱 들어맞는다. ex) Abs..