0206 ~ 0226

0214 - Thread dump와 Heap dump

개방용어로써 dump는 시스템에 저장된 정보를 복사하여 뽑은 것. 또는 그와 같은일로 쓰인다. 일종의 snapshot 개념인데 주로 분석 최적화에 많이 쓰인다. DB dump, Thread dump 등이 있다.

Thread Dump

• 프로세스에 속한 모든 thread들의 상태를 기록한것
• 여기서 말하는 thread들 중 일부는 JVM 내부 thread 이고 일부는 실행중인 애플리케이션의 thread이다
• Thread dump는 발생된 문제들을 진단, 분석하고 jvm 성능을 최적화하는데 필요한 정보를 보여준다
• 예를 들어 Thread dump는 자동으로 데드락을 표시한다

데드락이란? 운영체제 혹은 소프트웨어의 잘못된 자원 관리로 인하여 둘 이상의 프로세스(심하면 운영체제 자체도 포함)가 함께 멈추어 버리는 현상을 말한다
우리나라 말로 교착상태라고 한다
데드락은 두 개 이상의 Thread에서 작업을 완료하기 위해 상대의 작업이 끝나기를 기다린다

Heap Dump

• 특정 시점에 JVM heap 영역에 있는 모든 개체의 스냅샷
• 일반적으로 알고 있는 JVM 구조에서 heap 영역을 생각하면 된다
• GC가 힙에서 불필요한 객체를 제거하지 못하는경우 Java VisualVM을 사용하여 해당 객체에 대한 정보를 얻어낼 수 있

[ Heap Dump 떠보기 ]

# 실시간 분석하기
jmap -heap <PID>

# 파일로 출력하기
jmap -dump:format=b,file=<FILE_OUTPUT> <PID>

0222 - @Transient

@Transient는 엔티티 객체의 데이터와 테이블의 컬럼과 매핑하고 있는 관계를 제외하기 위해 사용한다.

@Entity  
public class Member{  
    @Id  
    private Long id; // PK  
    private String userId; // 사용자 아이디  
    private String password; // 비밀번호  
    private String confirmPassword; // 비밀번호 재입력  
}

@Entity  
public class Member{  
    @Id  
    private Long id;  
    private String userId;  
    private String password;  
  
    // [1] @Transient 선언  
    javax.persistence.@Transient  
    private String confirmPassword; // 비밀번호 재입력 매핑 제외  
}

@Transient 이해

@Transient는 JPA의 표준이라 할 수 있는 javax.persistence 패키지에 포함되어있는 컬럼을 제외하기(영속 대상에서 제외 시키기) 위해 사용하는 컬럼 매핑 레퍼런스 애노테이션이다.

package javax.persistence;  
@Target({ElementType.METHOD, ElementType.FIELD})  
@Retention(RetentionPolicy.RUNTIME)  
public @interface Transient {}

@Transient는 메서드와 필드에 선언할 수 있고 @Entity 클래스뿐만아니라 @MappedSuperclass, @Embeddable 클래스의 필드나 getter 메서드에 선언할 수 있다.

Specifies that the property or field is not persistent. It is used to annotate a property or field of an entity class, mapped superclass, or embeddable class. - Oracle Doc - @Transient (opens new window)

[ 영속 대상에서 제외 ]

무엇보다 영속(persistence)이라는 개념은 JPA의 가장 근간이 되는 개념이다. 다시 말해 JPA에선 영속성 컨텍스트(Persistence context)라는 논리적인 패러다임의 구현체라 할 수 있는 엔티티 매니저(Entity Manager)가 존재하고, 이 엔티티 매니저에서 @Entity 객체를 관리하게 된다. 엔티티 객체의 상태가 영속 상태(managed, persistent state)일 때, 비로소 엔티티 매니저에 의해 관리된다. 영속 상태의 엔티티 객체는 엔티티 매니저에 의해 [1] 변화에 대한 자동 감지(Dierty Checking), [2] CRUD SQL 자동 생성 작업 및 그외 일련의 모든 JPA의 내부적인 동작 프로세스에서 활용된다.

하지만 영속 대상에서 제외된다면, 더는 해당 필드나 메서드는 엔티티 매니저의 관리 대상에서 제외됨을 의미한다. 즉 해당 필드에 대해 @Transient 애노테이션을 선언하게 되면 영속 대상에서 제외되어 앞서 설명한 [1, 2] 작업들을 수행하지 않는다. 이러한 결과를 토대로 "테이블의 컬럼과 매핑을 하지 않는다."라고 이해해도 무방하다.

@Transient 간단한 예시와 사용법

@Entity  
public class Product {  
    @Id  
    private Long id;  
    private String name;  
    private BigDecimal price;  
    private boolean isEvent;  
    // ^-- 영속 제외 대상  
  
    public void runEventProcess(){  
        if(isEvent){  
            // ... 이벤트 로직 수행  
        }  
    }  
}

isEnvent 필드의 경우 Hokking 목적으로 특정 날짜나 시간이 되면 활성화(true)되어, 상품 가격에 대한 할인율 적용과 같은 상품에 대한 이벤트 로직을 적용 시키기 위함이다.

이처럼 특정 필드에 대해 클래스에서만 사용되고, 테이블 컬럼으로 관리하고 싶지 않을 경우에 사용한다.

Hibernate:  
        create table product (  
        id bigint not null,  
        is_event boolean not null, <-- 영속 제외 대상  
        name varchar(255),  
        price decimal(19,2),  
        primary key (id)  
        )

[ @Transient 두 가지 방식 ]

@Transient 애노테이션은 두 가지 방식을 통해 선언할 수 있도록 제공하고 있다.

• ElementType.FIELD

@Entity  
public class Product{  
    @Id  
    private Long id;  
    private String name;  
    private BigDecimal price;  
    @Transient  
    private boolean isEvent;  
    // ^-- 해당 필드 영속 제외 대상  
}

• ElementType.METHOD

@Entity  
public class Product{  
    private Long id;  
    private String isEvent;  
  
    @Id @GeneratedValue  
    public Long getId(){ return this.id; }  
    public void setId(Long id){ this.id = id; }  
    // ^-- @GeneratedValue는 JPA의 내부적인 프로세스에 의해  
    // setter 메서드를 통해 데이터를 셋팅하기 때문에 구성함  
    @Transient // <-- 해당 메서드 영속 제외 대상  
    public String getIsEventProduct(){ return this.isEvent; }  
}

다음 코드는 필드 방식과 마찬가지로 같은 결과를 수행하게 된다. 주의할 점은 setter 메서드가 아닌, getter 메서드에 애노테이션을 선언해줘야 한다.

메서드/필드 방식을 지원하는 JPA 애노테이션의 주의사항

[ 개발 의도와는 다르게 동작하는 JPA ]

@Entity  
public class Member{  
    @Id  
    private Long id;  
    private String userId;  
    private String password;  
    private String confirmPassword;  
  
    @Transient // <-- 문제가 되는 부분  
    public String getComfirmPassword(){ return this.confirmPassword; }  
}

• confirmPassword 필드를 영속 대상에서 제외한다.
• getComfirmPassword() 메서드에 @Trasient 애노테이션 선언
• 기대하는 결과 -> 테이블 컬럼 생성 및 CRUD SQL문 대상 컬럼 제외

Hibernate:  
        create table member (  
        id bigint not null,  
        user_id varchar(255),  
        password varchar(255),  
        confirm_password varchar(255), <-- 하지만 영속 대상에서 제외되지 않음  
        primary key (id)  
        )

하지만 실제 코드는 다르게 동작된다.

[ 문제의 원인 파악 - 엔티티 접근 방식에 대한 이해 ]

JPA 스펙에 따르자면, JPA는 두 가지 방식을 통해 영속 상태(managed, persistent state)인 엔티티 객체의 데이터에 접근할 수 있다.

1. 프로퍼티 방식(getter/setter Method, JavaBeans Property 스타일)
2. 필드 방식(Instance Fileds)

JPA 1.0(JSR 220) (opens new window)
JPA 2.0(JSR 317) (opens new window)
JPA 2.1(JSR 338) (opens new window)

// [1] 필드 방식  
@Entity  
public class Member{  
    @Id  
    private Long id;  
    private String name;  
    ...  
}  
  
// [2] 메서드 방식  
@Entity  
public class Member{  
    private Long id;  
    private String name;  
  
    @Id
    public Long getId(){return this.id;}  
    public void setId(Long id){this.id = id;}  
  
    public String getName(){return this.name;}  
    public void setName(String name){this.name = name;}  
}

JPA의 두 가지 접근 방식 중 선택하여 개발할 수 있도록, 필드 레벨에 선언시킬 수 있는 모든 JPA의 애노테이션들은 기본적으로 Property 방식을 지원하기 위해 메서드 레벨을 지원한다.

여기서 중요한 핵심은 설계 방식에 따라 JPA는 엔티티 객체의 접근 방식이 다르게 결정된다. 기본적으로 엔티티 매니저의 1차 캐시는 Map<@Id, @Entity> 형태로 설계되어 key에 해당하는 @Id와 value에 해당하는 엔티티 객체를 저장하여 관리한다.

결과적으로 JPA의 엔티티의 접근 방식은 @Id 애노테이션의 위치에 의해 결정되며, 엔티티의 모든 필드 또는 상속된 엔티티의 계층에 대해서도 일관성 있게 적용해줘야 한다.

엔티티의 계층에 대해서도 일관성 있게 적용해줘야 합니다.  
  
@Entity  
public class Member{  
    @Id // 필드 방식  
    private Long id;  
    private String userId;  
    private String password;  
    private String confirmPassword;  
  
    @Transient // JPA에서 인식 불가 → 동작 안함  
    public String getComfirmPassword(){ return this.confirmPassword; }  
}

따라서 다음 문제가 된 엔티티 구조에선 @Id 애노테이션의 위치가 필드에 있으므로 JPA는 필드 접근 방식을 따르게 된다. 이러한 이유로 confirmPassword 필드는 영속 대상에서 제외되지 않는다.

[ 정리 ]

1. @Transient는 영속 대상에서 제외한다.
2. JPA 컬럼 매핑 레퍼런스 애노테이션은 Filed, Property 방식을 지원하기 위해 필드와 메서드에 선언할 수 있다.
3. 컬럼 매핑 레퍼런스 애노테이션을 사용할 때 JPA의 엔티티 접근 방식을 살펴보자.
   • @Id 애노테이션의 위치를 보자.(@Access 애노테이션으로 접근 방식을 재정의하지 않는 이상)
4. QueryDSL 또한 JPA의 엔티티 접근 방식을 기준으로 QDomain 클래스를 생성한다.
   • 또한, @Transient 애노테이션이 선언된 필드나 메서드는 QDomain 클래스의 쿼리 타입 생성과정에서 제외된다.

0224 - Instant vs LocalDateTime

Instant

• Instant 클래스는 단어의 의미와 같이 순가, 즉시를 의미한다.
• 컴퓨팅을 하기 위해 Timestamp로 기술적인 표현을 한 것.
  • 즉, 인간보다는 기계에 친화적이다.
• long 형태로 Unix Timestamp를 저장하기 때문에 연산이 빠르다.
• Unix Timestamp 는 Year 2038 problem 문제가 있어 이를 보완한 것이 Instant 클래스이다.
• 지원 범위
  • MIN_SECOND = -10000000-01-01T00:00Z
  • MAX_SECOND = 1000000000-12-31T23:59:59.99999999Z

private static final long MIN_SECOND = -31557014167219200L; 
private static final long MAX_SECOND = 31556889864403199L;

• 객체 생성

Instant now = Instant.now();
println(now); 
// 2022-08-08T16:09:17.105081Z -- 2022년 08월 09일 01시 09분 17초

• 나노초까지 표현 가능(뒤에 Z를 표현함)
• Timestamp는 본래 long타입이다. toString()을 재정의 함.

public static Instant now(){  
        return Clock.currentInstant();  
        }  
  
public abstract class Clock {  
    private static final long OFFSET_SEED = System.currentTimeMillis() / 1000 - 1024;  
    private static long offset = OFFSET_SEED;  
  
    // 시스템의 현재 시간을 가져온다 나노초로 가져오는 것을 밀리초로 표현해준다.  
    static Instant currentInstant() {  
        long localOffset = offset;  
        long adjustment = VM.getNanoTimeAdjustment(localOffset);  
        // 밀리초를 나노초로 변환해서 가져온다  
            ...  
        return Instant.ofEpochSecond(localOffset, adjustment);  
    }  
}

LocalDateTime

• LocalDateTime은 날짜 + 시간 정보를 가지고 있다. Timezone이 없다.
• LocalDateTime은 인간에게 친화적인 타입
• LocalDateTime은 현재 로컬 시간에 맞춰서 시간을 표현

LocalDateTime now = LocalDateTime.now(); 
println(now); 
// 2022-08-09T01:09:17.113332 2022년 08월 09일 01시 09분 17초

• 인스턴스의 Tiemzone 기반으로 Offset을 생성한 후 현재 시점 기준으로 LocalDate, LocalTime 객체를 생성 후 LocalDateTime을 생성한다.

public final class LocalDateTime {  
    public static LocalDateTime now() {  
        return now(Clock.systemDefaultZone());  
    }  
}  
  
    public static Clock systemDefaultZone() {  
        // 시스템의 ZoneId를 가져온다   
return new SystemClock(ZoneId.systemDefault());  
    }  
  
    public static LocalDateTime now(Clock clock) {  
        Objects.requireNonNull(clock, "clock");  
        final Instant now = clock.instant();  
        // ZoneId를 기반으로 Offset 정보를 가져온다.   
ZoneOffset offset = clock.getZone().getRules().getOffset(now);  
        return ofEpochSecond(now.getEpochSecond(), now.getNano(), offset);  
    }  
  
    public static LocalDateTime ofEpochSecond(long epochSecond, int nanoOfSecond, ZoneOffset offset) {  
        Objects.requireNonNull(offset, "offset");  
        NANO_OF_SECOND.checkValidValue(nanoOfSecond);  
        long localSecond = epochSecond + offset.getTotalSeconds();  
        long localEpochDay = Math.floorDiv(localSecond, SECONDS_PER_DAY);  
        int secsOfDay = Math.floorMod(localSecond, SECONDS_PER_DAY);  
        LocalDate date = LocalDate.ofEpochDay(localEpochDay);  
        LocalTime time = LocalTime.ofNanoOfDay(secsOfDay * NANOS_PER_SECOND + nanoOfSecond);  
        return new LocalDateTime(date, time);  
    }

[ LocalDateTime을 사용 했을 때 문제점 ]

• 글로벌 환경의 경우 UTC를 따로 설정해 주지 않는 이상 각각 Timezone에 맞춰 데이터가 생성된다.

[ 어떤 상황에 사용하는 것이 적합할까 ]

• Timestamp를 UTC 형식으로 저장하는 곳 즉 DB, 백엔드 비즈니스 로직, 데이터 교환, 직렬화 시나리오에 적합하다.(연산하기 쉬움)
• 글로벌 런칭한 서비스 비즈니스 앱 개발 시 Instant 나 ZonedDateTime 클래스를 많이 사용