java

https://velog.io/@ililil9482/Java17을-고려해야할까https://techblog.gccompany.co.kr/우리팀이-jdk-17을-도입한-이유-ced2b754cd7기존 java의 jar 패키징을 통해 모듈화를 진행하고 있지

Java 8의 Optional은 내부 구현과 설계 철학을 이해하면 언제, 어떻게 써야 하는지가 훨씬 또렷해집니다.Optional은 매우 얇은 래퍼 객체입니다.핵심은 “값이 있거나(empty) 둘 중 하나의 상태를 표현하는 불변 객체”라는 점입니다.내부 필드는 보통 하나

위 사진을 보면 알 수 있듯ArrayList는 index가 있고, LinkedList는 각 원소마다 앞,뒤 원소의 위치값을 가지고 있다. 이러한 각각의 특징은 조회, 삽입, 삭제시에 성능의 차이를 발생시킨다.ArrayList는 기본적으로 배열을 사용한다.하지만 일반 배

에러(Error)예외(Exception)체크 예외(Check Exception)언체크 예외(Uncheck Exception)java.lang.Error 클래스의 하위 클래스들이다. Error는 메모리가 부족하는 등과 같이 시스템이 비정상적인 상황인 경우에 사용한다. 주

자바에서 예외 처리 관련해서 자주 보는 문법은 크게 세 가지다.try-catchtry-finallytry-with-resources이 셋은 서로 대체 관계라기보다는, 역할이 조금씩 다른 도구 세트라고 이해하는 게 좋다.try-catch의 목적은 예외를 잡아서 처리/전환

자바 제네릭을 어느 정도 쓰다 보면, “왜 List<Integer>는 List<Number>의 하위 타입이 아니지?”, “? extends랑 ? super는 대충 알겠는데 막상 쓰려니 헷갈린다” 같은 지점에서 자주 막힌다. 이 글에서는 변성(공변/불공변)을

자바에서는 Stack 클래스를 따로 지원해주지만 우리는 직접 구현해보는 것을 목표로 할 것이다. 일단은 자바의 Stack 클래스의 함수 부터 살펴 보자.기본적으로 Stack은과 같이 생성 할 수 있다.Stack 클래스는 기본적으로이 5가지의 함수를 지원해준다. 지금 부

스택 두 개를 준비한다.Stack 1 : add() 할 때만 사용할 것입니다. (추가할 때만 사용)Stack 2 : peek(), poll() 을 할 때 사용할 것입니다. (읽는 연산이 필요할 때 사용)add1번 스택에 원소를 넣는다.poll1번 스택에 있는 원소들을

PriorityQueue란 우선순위 큐로써 일반적인 큐의 구조 FIFO(First In First Out)를 가지면서, 데이터가 들어온 순서대로 데이터가 나가는 것이 아닌 우선순위를 먼저 결정하고 그 우선순위가 높은 데이터가 먼저 나가는 자료구조이다.PriorityQu

자바 volatile 키워드 정리 · 멀티스레드에서 이거 모르면 골치 아파짐 😅1멀티 스레드 코드를 짜다 보면, 가끔 이런 기분 나쁜 일이 생긴다.3분명 한 스레드에서 값을 바꿨는데,다른 스레드는 그 값을 한참 뒤에 보거나, 심하면 영원히 못 보기도 한다.이유는 단순

Java 8 스트림 API를 쓰다 보면 한 번쯤 이런 코드가 나온다.스레드 풀 만들 필요 없음.parallelStream() 한 줄로 멀티코어를 알아서 써준다.내부적으로는 ForkJoinPool + Work Stealing 구조를 사용한다.그래서 대량 데이터 처리할 때

멀티스레드 환경에서 안전하게 사용할 수 있는 Map 구현체로 자바는 오랫동안 Hashtable을 제공해 왔습니다.하지만 시간이 지나면서 더 높은 성능과 동시성이 요구되었고, 그 결과로 ConcurrentHashMap을 포함한 concurrent 컬렉션들이 등장하게 되었

1. 왜 굳이 “참조 객체”까지 써야 할까? 자바의 GC 덕분에 new만 적당히 써도 메모리 관리는 어느 정도 자동으로 돌긴 한다. 하지만 “언제, 어떤 객체를 먼저 수거할지”를 조금 더 미세하게 제어하고 싶을 때가 있다. 캐시는 “메모리가 넉넉할 땐 오래 들고

1. 강한 참조 Map으로 생기는 은근한 메모리 누수 예제 코드: work()를 수천 번 호출하면? key는 지역 변수라 스코프를 벗어나면 GC 대상이 되지만, cache가 키를 강하게 들고 있어서 키·값 둘 다 계속 살아 있음. 결과적으로 HashMa

기존 GC(특히 CMS/Parallel GC)는 힙이 커질수록 Stop-the-world(STW) 시간이 길어지는 문제가 있었다.온라인 서비스, 대규모 자바 서버에서는 몇 초짜리 STW만 나와도 바로 장애로 이어지니, “예측 가능한 짧은 pause”가 핵심 요구사항이