ecsimsw

GC와 Stop the world JVM의 가비지컬렉터는 힙 영역의 메모리에서 더 이상 사용되지 않는 자원을 정리하는 역할을 한다. 이때 사용되지 않는다란 다른 지역 변수, static 변수, 파라미터, JNI의 객체, 다른 힙 영역의 객체 등에서 더 이상 참조되지 않는 것을 말한다. 아래 그림에서 빨간색으로 표시된 Unreachable objects는 GC의 대상이 된다. 이때 자원을 정리하는 과정에서 새로운 객체가 할당되거나 객체 간 연결이 생길 경우를 방지하기 위해, GC를 위한 스레드를 제외한 모든 스레드의 작업이 중단된다. 이런 GC를 위한 애플리케이션 전체 중단 시간을 Stop the world라고 한다. ( 보다 자세한 STW가 필요한 이유 ) 두가지 GC와 처리 영역들 Stop the wo..

Local Maven Repository에 Gradle project 라이브러리 배포 1. build.gradle 수정 - plugins : 'java' -> 'java-library' 수정 / id 'maven-publish' 추가 plugins { id 'java-library' id 'maven-publish' } - 라이브러리 정보 기입 publishing { publications { maven(MavenPublication) { groupId = 'com.ecsimsw.fastCrud' // groupId artifactId = 'library' // artifactId version = '0.0.1-SNAPSHOT' // version from components.java } } } 2. s..

Optional로 Null 을 알리는 습관 어떤 로직의 계산 결과가 없음을 알리는 방법으로 가장 쉬운 것은 역시 null을 반환해버리는 것이라고 생각한다. 그 계산 결과를 받아서 처리하는 다음 로직에서 null을 어떻게 처리할지를 전혀 신경쓰지 않는다면 말이다. 그렇다면 반환된 결과가 null인지 매번 if문으로 체크를 해야할 것이다. null이 가능함을 생각하지 못하고 오류를 만들 여지가 있고, 처리한다고 하더라도 가독성이 좋지 못한 코드를 만들어야할 것이다. 자바에서도 직접적인 null 비교 (ex, car == null)를 피할 수 있도록 Objects 클래스에 isNull(), nonNull(), requireNonNull() 과 같은 메소드를 제공하고 있다. Optional을 사용하면 계산의 결..

HashSet의 출력이 고정된 것 같아 (@조엘) 우아한테크코스에서 함께 공부하는 친구가 좋은 대화 주제를 찾아주었다. 어느날 찾아와서는 HashSet의 순서에도 뭔가 규칙이 있을 것 같다는 얘기를 하는 것이다. public class HashSetExample { public static void main(String[] args) { HashSet hashSet = new HashSet(); hashSet.add("1"); hashSet.add("2"); hashSet.add("3"); hashSet.add("4"); hashSet.add("5"); hashSet.add("6"); hashSet.add("7"); hashSet.add("8"); hashSet.add("9"); hashSet.add("..

0. '좋은 코드'을 먼저 정의하자. 성능이 우선시 되어야 하는 상황, 가독성이 우선시 되어야 하는 상황 꼼꼼한 예외처리와 테스트가 우선시 되어야하는 상황, 빠르게 구현이 먼저 필요한 상황 객체지향, 테스트 코드, 성능을 생각하다가 가독성이 떨어지는 상황을 만들고 싶진 않다. 1. 불변 객체를 만들자 객체를 신뢰할 수 있다. Thread-safe하다. 참조가 꼬이는 일이 없다. Collections.unmodifiableList 보다는 방어적 복사를 사용한다. (참조 자체를 끊는다) 2. 컨트롤러의 다이어트가 필요하다. 컨트롤러는 조립하는 역할로 생각한다. 컨트롤러에 속성를 두지 않는다. / 상태를 만들지 않는다. 컨트롤러가 더럽다면 로직을 추상화해서 관련 객체와 로직을 포함하는 도메인 객체 또는 서비스..

배열, 리스트 선택의 근거 잡기 같은 타입의 여러 객체를 단순히 참조만 하는 용도에는 배열이 좋다고 생각했다. 리스트보다 배열이 메모리 관리에 유리하다는 자료구조 책의 한 문장을 기억했지 그 이상을 알려하지 않았다. 배열과 리스트 중 어떤 것을 사용해야하는 지 선택의 근거를 나름대로 잡아보려 한다. 배열보다는 리스트를 사용하라 'Effective Java 규칙 28. 배열보다는 리스트를 사용하라'는 배열보다 리스트 사용을 권장하고 있다. 그 이유를 공부해왔다. 아래처럼 배열을 사용할 경우, ArrayStroreException을 컴파일 시점에선 알 수 없다. 배열은 공변형이고, 런타임에서야 원소의 자료형이 결정되기 때문에, 런타임에서야 그 실수가 드러난다. Object[] objArr = new Long..

oracle docs - Collections.unmodifiableList() Returns an unmodifiable view of the specified list. This method allows modules to provide users with "read-only" access to internal lists. Query operations on the returned list "read through" to the specified list, and attempts to modify the returned list, whether direct or via its iterator, result in an UnsupportedOperationException. UnmodifiableList..

Variable 'i' should be final or effectively final 자바에서 람다식과 inner class에서는 final 변수 또는 effectively final 변수만 접근된다. 충분히 가능할 것만 같은 코드가 왜 컴파일 에러를 만드는지, effectively final 변수는 뭔지 정리해보려고 한다. public static void testLamda(String[] args) { int i = 0; Runnable testExpression = () -> i++; } // Variable used in lambda expression should be final or effectively final 람다 캡쳐링 아래 코드를 한번 보자. class test { public s..