HaileyKim

@Jacksonized

haileykim2014 — Tue, 6 Jun 2023 17:29:13 +0900

회사에서도 직렬화/ 역직렬화를 위해 사용하는 jackson 라이브러리.

마침 넥텝 과제하던 중 알게된 어노테이션 @Jacksonized를 정리해본다.

Jackson 라이브러리란 ?

spring-boot-starter-web 의존성을 주입하면 자동으로 이 라이브러리가 포함된다.

JSON 컨버팅할때 jackson을 사용하게된다.

@Jacksonized

역직렬화를 위한 어노테이션이다.

불변성을 보장하면서 역직렬화를 가능하게 한다.

@Jacksonized 어노테이션은 @Builder 또는 @SuperBuilder와 함께 사용한다.

이 어노테이션은 생성된 빌더 클래스를 Jackson의 역직렬화에 사용할 수 있도록 자동으로 구성합니다.

@Builder 또는 @SuperBuilde가 적용된 상황에서만 가능하다.

빌더의 동작을 변경하지 않는다.

@Jacksonized @Builder
@JsonIgnoreProperties(ignoreUnknown = true)
public class JacksonExample {
	private List<Foo> foos;
}

예시 코드

@Getter
@Builder
@Jacksonized
class JacksonExample {
  private final String name;
  private final int age;
}

class JacksonExampleTest {
  @Test
  void testJacksonSerializationAndDeserialization() throws IOException {
    // 객체 생성
    JacksonExample example = JacksonExample.builder()
        .name("Bob")
        .age(25)
        .build();

    // ObjectMapper를 사용하여 객체를 JSON 문자열로 직렬화
    ObjectMapper objectMapper = new ObjectMapper();
    String json = objectMapper.writeValueAsString(example);

    // JSON 문자열을 사용하여 객체를 역직렬화
    JacksonExample deserializedExample = objectMapper.readValue(json, JacksonExample.class);

    // 값 비교
    assertEquals("Bob", deserializedExample.getName());
    assertEquals(25, deserializedExample.getAge());
  }
}

JackonExample 클래스에 @Jacksonized 어노테이션을 적용했다.
Jackson 의 직렬화 및 역직렬화에 사용되는 빌더 클래스를 자동으로 구성한다.
위 테스트 코드에서 객체를 생성하고 ObjectMapper를 사용하여 해당 객체를 json문자열로 직렬화 한후 다시 역직렬화한다.
역직렬화된 객체의 값과 원래의 값이 일치하는지 확인한다.

플젝 적용

아래는 넥텝 과제에 적용한 내 코드 일부분이다.

package cart.dto;

import cart.domain.Cart;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Getter;
import lombok.extern.jackson.Jacksonized;

@Getter
@AllArgsConstructor
@Jacksonized
@Builder
public class CartCreateDto {

  private final Long productId;
  private final int count;

  public Cart toEntity(Long memberId) {
    return Cart.builder()
        .productId(getProductId())
        .memberId(memberId)
        .count(getCount())
        .build();
  }
}

@Jacksonized 어노테이션을 사용해서 CartCreateDto 클래스가 Jackson과 함께 동작한다.
Jacksonized 어노테이션과 Builder 어노테이션을 같이 사용해 빌더 패턴이 생성된다.
위 클래스의 객체를 Json 형식으로 직렬화해서 요청 바디에 넣는 테스트 코드를 작성하여 직렬화를 처리한다.

  @DisplayName("로그인한 유저의 장바구니에 상품을 추가한다.")
  @Test
  void addItemToCart() {
    CartCreateDto createDto = CartCreateDto.builder()
        .productId(1L)
        .count(1)
        .build();

    var result = given()
        .auth().preemptive().basic(member.getEmail(), member.getPassword())
        .contentType(MediaType.APPLICATION_JSON_VALUE)
        .accept(MediaType.APPLICATION_JSON_VALUE)
        .body(createDto)
        .when().post("/carts/add-to-cart")
        .then().log().all()
        .extract();

    assertThat(cartService.cartProducts(member).size()).isEqualTo(2);
    assertThat(result.statusCode()).isEqualTo(HttpStatus.OK.value());
  }

요청을 보낼때 createDto 객체가 요청 바디에 담겨 전송된다.
서버에서 json 바디를 역직렬화하여 cartCreateDto 객체로 변환한다.

참고

https://www.baeldung.com/java-jackson-deserialization-lombok

https://projectlombok.org/features/experimental/Jacksonized

객체지향

haileykim2014 — Thu, 23 Mar 2023 02:45:41 +0900

프로그래밍 패러다임

패러다임

한 시대의 사회전체가 공유하는 이론이나 방법, 문제 의식등의 체계

프로그래밍 패러다임

특정 시대의 어느 성숙한 개발자 공동체에 의해 수용된 프로그래밍 방법과 문제 해결 방법, 프로그래밍 스타일.

우리가 어떤 프로그래밍 패러다임을 사용하느냐에 따라 우리가 해결할 문제를 바라보는 방식과 프로그램을 작성하는 방법이 달라진다. 프로그래밍 언어마다 채택하는 프로그래밍 패러다임이 다르다.

패러다임 전환

절차형 패러다임에서 객체지향 패러다임으로의 변화를 가리킨다.

프로그래밍 패러다임의 역할

개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다.

또한 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장하도록 준비시킬 수 있다.

특정한 종류의 문제를 해결하는데 필요한 일련의 개념들을 지원한다.

소극장 애플리케이션의 문제

의도

Theater : 관람객을 입장

TickerSeller : 티켓을 판매

Audience : 티켓 구매

1. 예상을 빗나가는 코드 예시

내가 관람객이라고 가정할때, 관람객의 입장에서 소극장이라는 제3자가 초대장을 확인하기 위해 관람객의 가방을 마음대로 열어본다.

의도 : 티켓을 구매하는 관람객이 가방 안에서 돈을 직접 꺼내 판매원에게 지불한다.

2. 변경에 취약한 코드 예시

의존성 문제. 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체로 함께 변경될 수 있다.

Theater가 Audience와 TicketSeller의 상세한 내부 구현까지 알고 있어야 한다.

설계 개선

// 문제코드
public class Theater{
	private TicketSeller ticketSeller;
    
    public Theater(TicketSeller ticketseller){
    this.ticketSeller = ticketSelelr;
    }
    
    public void enter(Audience audience){
        if(audience.getBag().hasInvitation()){ //TicketSeller의 sellTo()메소드로 옮긴다. TicketSeller의 내부구현을 캡슐화
            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().setTicket(ticket);
        }else{
            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().minusAmount(ticket.getFee());
            ticketSeller.getTicketOffice().plusAmount(ticket.getFee());
            audience.getBag().setTicket(ticket);
        }
	}
}

//개선 코드
public class Theater {
	private TicketSeller ticketSeller;
    
    public Theater(TicketSeller ticketSeller){
    	this.ticketSeller = ticketSeller;
        }
    
    public void enter(Audience audience){
    	ticketSeller.sellTo(audience); //TicketOffice에 접근하는 로직을 모두 ticketSeller.sellTo에 숨김
        }
    }

1. 자율성을 높이기

관람객과 판매원을 자율적인 존재로 만든다.

Theater가 TicketSeller와 Audience에 세세한 부분까지 알지 못하도록 정보를 차단한다.

관람객이 스스로 가방 안의 현금과 초대장을 처리하고 판매원이 스스로 매표소의 티켓과 판매 요금을 다루게 한다.

1.1 캡슐화 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것.

객체 내부로의 접근을 제한해 객체와 객체 사이의 결합도를 낮춘다. -> 설계를 좀더 쉽게 변경 가능

접근 가능한 퍼블릭 메서드가 존재하지 않기때문에 외부에서 ticketOffice에 직접 접근할 수 없다. 오직 TicketSeller안에만 존재하게 된다.

1.2 수정된 Theater class 어디서도 ticketOffice에 접근하지 않는다.

Theater 는 ticketOffice가 TicketSeller내부에 존재하는 사실을 모른다.

Theater는 오직 TicketSeller 인터페이스에만 의존한다.

객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성한다.

2. 자신의 문제해결

판매자가 티켓을 판매하기 위해 ticketOffice를 사용하는 모든 부분을 TicketSeller 내부로 옮기고, 관람객이 티켓을 구매하기 위해 Bag을 사용하는 모든 부분을 Audience 내부로 옮긴다.

자신의 문제를 스스로 해결하도록 코드를 변경한다.

개선된 점

변경 용이성이 개선

TicketSeller의 내부 구현을 변경하더라도 Theater를 함께 변경할 필요가 없다. TicketSeller가 매표소가 아니라 은행에 돈을 보관하도록 만들고 싶으면 TicketSeller내부만 변경하면 된다.

책임의 이동

기존 코드는 책임이 Threater에 집중되어 있었다.

독재자가 존재하지 않고, 각 객체에 책임이 적절하게 분배된다.

데이터와 데이터를 사용하는 프로세스가 동일한 객체 안에 존재한다.

절차지향

개선전의 Theater는 절차적 프로그래밍이다.

Theater enter메서드는 프로세스이며, Audience, TicketSeller, Bag, TicketOffice는 데이터이다.

프로세스를 담당하는 Theater가 Audience, TicketSeller, Bag, TicketOffice 모두에 의존하고 있었다. 모든 처리가 하나의 클래스 안에 위치하고 나머지 클래스는 단지 데이터의 역할만 수행했다.

프로세스와 데이터를 별도의 모듈에 위치시키는 방식이 절차지향이다.

객체지향 설계

자신의 문제를 스스로 처리하기 때문에 예측이 가능하고, 이해하기 쉬우며 객체 내부의 변경이 객체 외부에 파급되지 않도록 제어할 수 있어서 변경하기가 수월하다.
의존성 제거 : 불필요한 의존성을 제거-> 객체사이의 결합도를 낮추는 것
캡슐화 : Theater가 몰라도 되는 세부사항을 Audience와 TicketSeller 내부로 감춰 캡슐화

좋은 설계

변경을 수용할 수 있어야한다.

요구사항은 항상 변경된다.

오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계

How to Achieve More

haileykim2014 — Tue, 14 Mar 2023 22:28:50 +0900

걸스인텍&원티드에서 진행한 워크샵에 다녀왔다. 생각보다 신청자 수가 많았다. 5:1의 경쟁률이었다고 한다 워후

아름다운 광화문 뷰와 함께 토요일 아침을 알차게 보내고 왔다.

한국 마이크로소프트의 김성미 이사님께서 일하는 방법을 강연해주셨다 .김 이사님께서 공유해주신 소중한 경험담과 인사이트들을 정리해보았다.

꿈은 이루어진다 : 가짜 꿈들 사이에서 진짜 꿈을 찾는 과정에 시련이있다.
행복은 전염된다 : 기여는 건강한 에너지, 선순환을 만든다.
가슴 뛰는 일을 먼저하기 : 하고싶은 것에 일단 몸을 던지고, How to 고민하기
주말 아침 4시간을 내 시간으로 갖기 : 가장 빨리 열리는 카페에 출근하는 직원과 함께 들어가 나만의 시간을 보내기, 3개월 이상 유지하기
만다라트 기법으로 목표 세우고 성취하기

직종을 변경하면서도 긍정적인 에너지와 열정을 유지하는 방법을 배웠다. 워크샵이 끝나고 김성미 이사님께서 직접 친필 서명이 담긴 책을 선물해주셨다. 집에 돌아오면서 마음이 충만해진 느낌이었다. 세션에서 다 채우지 못한 내 만다라트도 채워봐야겠다. 그리고 다양한 분야에서 일하는 분들과 소통하면서 열정을 느낄 수 있어서 매우 좋았다.

걸스인텍 이벤트는 이번이 두 번째인데, 항상 알차고 얻어가는 것이 많다!

DB Connection Pool

haileykim2014 — Wed, 15 Feb 2023 03:26:09 +0900

DB connection pool과 스레드 개수는 메모리와 관련이있다.
많이 사용할 수록 메모리를 많이 점유한다.
개수를 적게 지정하면 서버에서는 많은 요청을 처리하지 못하고 대기하게된다.
WAS에서 기본 개수가 10~20개 정도이다.
DB connection pool은 보통 40~50개로 지정하고 스레드 개수는 이보다 10개 정도 더 지정한다.
스레드 개수 < DB connection pool : 스레드가 적은만큼 연결 필요가 없어진다.
스레드 개수 > DB connection pool : 여유분을 갖도록위함이다.
적합한 개수는 서버와 애플리케이션 상황에 따라 다르다.
서비스 및 서버의 상황에 맞게 값을 지정해야한다. -> 성능테스트
DB의 CPU 사용량이 100% 도달했다면 ? CPU를 점유하는 쿼리를 찾는다 -> 인덱스가 없거나, 테이블을 풀 스캔하는 쿼리가 있는지 , 쿼리의 플랜을 확인한다.
DB connection pool 지정 개수를 전부 사용한다고 개수를 막 늘리면 DB사용량이 늘고 응답 시간이 느려진다
DB의 CPU 사용량이 50% 미만이고 WAS의 CPU 사용량이 100%일때 : WAS의 애플리케이션을 튜닝한다. 이미 튜닝했다면 -> 커넥션풀을 늘리기, 서버 대수 늘리는것은 가장 마지막에 고려할 것

음..회사에서 DB의 CPU점유율이 상당히 높은 편이다..이유는 바로 가장많이 이용하는 부분의 쿼리들 때문!!

이 부분도 팀원들이랑 개선점 찾아서 진행하고싶다

Tree

haileykim2014 — Tue, 10 Jan 2023 01:36:48 +0900

트리

0개 이상의 다른 노드에 대한 레퍼런스가 들어 있는 노드로 구성

한 노드를 참조하는 노드는 하나

노드는 구조체, 클래스로 표현

포인터 또는 레퍼런스만 있다면 어떤 언어로든 구현 가능

보통 노드의 공통적인 부분을 하나의 클래스로 정의하고 노드에 들어가는 데이터를 서브클래스를 만들어서 사용

public abstract class Node{
	private Node[] children;

	public Node(Node[] children){
    	this.children = children;
    }
    
    public int getNumChildren(){
    	return children.length;
    }
    
    public Node getChild(int index){
    	return children[index];
    }
}

public class IntNode extends Node{
	private int value;
    
    public IntNode(Node[] children. int value){
    super(children);
    this.value=value;
    }
    
    public int getValue(){
    return value;
    }
}

부모 : 다른 노드를 가리키는 노드는 그 노드의 부모가 된다.

자식 : 루트를 제외한 모든 노드는 그 노드를 가리키는 노드의 자식이 된다.

자손 : 특정 노드로 부터 자식노드로 이어지는 경로를 따라 도달 할 수 있는 모든 노드는 그 특정 노드의 자손이다.

조상 : 어떤 노드를 자손으로 삼고 있는 노드는 모두 그 노드의 조상이다.

잎 : 자식이 없는 노드를 잎이라고 부른다

이진트리

한 노드에 자식이 최대 두개 까지만 있을 수 있으며 그 두 자식은 각각 왼쪽 자식과 오른쪽 자식이라고 부른다.

//이진트리
public class Node{
	private Node left;
    private Node right;
    private int value;
    
    public Node(Node left,Node right,int value){
    	this.left = left;
        this.right = right;
        this.value =value;
    }
    
    public Node getLeft(){return left;}
    public Node getRight(){return right;}
    public int getValue(){return value;}
}

이진 검색 트리

노드의 왼쪽 자식의 값이 반드시 자신의 값이하이며, 오른쪽 자식의 값은 반드시 자신의 값 이사이앋.

데이터가 값으로 정렬된다.

어떤 노드의 왼쪽 방향의 자손들은 전부 그 노드 이하의 값을 가지며 오른쪽 자손들은 모두 그 노드 이상의 값을 가진다.

룩업연산을 빠르고 간단하게 처리 할 수 있다.

Node findNode(Node root, int value){
	while(root != null){
    	int currval = root.getValue();
        if( currval == value) break;
        if( currval < value){
        	root = root.getRight();
        }else { // currval > value
        	root = root.getLeft();
        }
    }
    return root;
}

힙

노드의 각 자식의 값은 노드 자신의 값 이하여야한다

루트노드의 값은 그 트리에서 가장 큰 값이며 최댓값을 상수 시간으로 구하는 것이 가능하다

삽입과 삭제는 O(log(n))

룩업은 O(n)

ex, 병원 응급실에서 대기 중인 환자들을 힙으로 모델링

우선순위 부여

일반적인 검색 방법

너비 우선 검색

O(n)

어떤 층을 검색할 때 그 층에 있는 모든 노드의 자식노드를 저장해둬야 하기 때문에 메모리도 꽤 사용한다

깊이 우선 검색

원하는 노드를 찾을 때까지 또는 끝에 다다를 때까지 한 가지를 따라 쭉 내려가는 방식

종주 (traversal)

방법에 따라 노드를 방문하는 순서가 달라진다

프리오더 종주 : 항상 노드를 자식들보다 먼저 방문

인오더 종주 : 왼쪽 서브트리를 먼저 방문하고 노드 자체를 방문한 다음 오른쪽 서브 트리 방문

포스트오더 종주 : 왼쪽자손 작업 수행 후 오른쪽자손 작업 마지막으로 그 노드 자체 처리

재귀호출로 구현

null 대신 Optional 클래스

haileykim2014 — Mon, 2 Jan 2023 00:59:10 +0900

null 때문에 발생하는 문제

에러의 근원 : NPE
코드를 어지럽힌다. : 중첩된 null 확인 코드
형식 시스템에 구멍을 만듦 : null이 할당되면 시스템의 다른부분으로 null이 퍼졌을때 애초에 null이 어떤 의미로 사용되었는지 알 수 없음

Optional클래스를 사용

메서드의 시그니처만 보고도 선택형 값인지 여부를 구별 할 수 있다.

public class Person{
	private Optional<Car> car; //사람이 차를 소유했을 수도 소유하지 않았을 수도 있다
    public Optional<Car> getCar();{
    	return car;
        }
    }

Optional 사용

잠재적 null이 될 수 있는 대상을 Optional로 감싸기
팩토리메서드 Optional.empty , Optional.of , Optional.ofNullable 이용해서 Optional 객체 만들기

Optional<Object> value = Optional.ofNullable(map.get)"key"));

GC

haileykim2014 — Sun, 1 Jan 2023 18:13:51 +0900

Garbage-First Garbage Collector.pdf

0.33MB

GC : 프로그램이 동적으로 할당했던 메모리 영역중 필요업게 된 영역을 알아서 해제

장점 : 메모리 누수 방지, 해제된 메모리 접근 방지, 해제한 메모리의 해제 방지

단점 : GC작업은 순수 오버헤드

GC알고리즘

Reference counting
1. 힙영역에 선언된 객체들이 레퍼런스카운트 숫자를 갖는다.
2. 레퍼런스 카운트가 0이면 GC대상
3. 순환참조 문제발생 (메모리 릭 발생)
Mark and sweep
1. 순환 참조 문제해결
2. 루트에서부터 해당 객체에 접근가능한지 기준
3. Mark : 루트부터 연결된 객체찾는것 (reachable)
4. Sweep : 연결이 끊어진 객체 지우는것(unreachable)
5. Compaction : 메모리 파편화 막음 (필수 아님)
  1. Sweep 후에 분산된 객체들을 Heap의 시작 주소로 모아 메모리가 할당된 부분과 그렇지 않은 부분으로 압축한다
6. 단점 : 의도적으로 GC실행 시켜야함, 어플리케이션과 GC실행이 병행

Root space

JVM메모리의 stack의 로컬변수 , method area에 저장된 static변수 , native method stack의 C/C++ 작성되 JNI참조

Heap :

Young
1. Eden : minor GC
2. Survival 0 : minor GC
3. Survival 1 : minor GC (서바이벌0,1 둘중하나만차야함)
Old : (young -> old : promotion)
1. Major GC 발생

대부분 객체가 수명이 짧음

메모리의 특정부분만 처리(영부분)

Stop the world

GC실행을 위해 JVM이 어플리케이션 실행을 멈추는것

GC 방식

Serial GC
1. 하나의 스레드로 GC실행
2. Stw 시간이 김
3. 싱글 스레드 환경 및 heap이 매우 작을때 사용
4. compaction
Parallel GC
1. 여러개의 스레드로 GC실행
2. 멀티코어 환경에서 사용
3. Java8 default GC
4. Compaction (mark-summary-compaction)
CMS (concurrent mark sweep)
1. stw시간을 최소화하기위해 고안
2. GC 작업을 어플리케이션과 동시에 실행
3. G1 GC 등장에 따라 deprecated
4. compaction이 기본적으로 제공되지않음
G1 GC
1. heap을 region으로 나누어 관리
2. Java9 default
3. Compaction 작업수행
4. Heap을 일정크기의 리전으로 잘게 나눠서 어떤영역은 올드 ,영으로 나눠서 튜닝한다.전통적인 GC 힙구조와 달리 young 이나 old 영역이 인접해 있지 않고 영역의 사이즈에 따라서 동적으로 바뀔 수 있다.
5. G1 GC는 영역의 개념이 물리적으로 존재하지 않고 논리적으로 존재함으로써 공간과 시간을 아낄 수 있다.
6. 메모리가 많이 차있는 리전을 인식하는 기능을 통해 메모리가 많이 차있는 리전을 우선적으로 GC한다.
7. https://luavis.me/server/g1-gc

Compaction :

더 이상 참조되지 않는 오브젝트가 해제된 이후 오브젝트들 사이의 빈공간을 없애기 위해 재배치
여유 공간을 큰 덩어리로 통합
선형
TLAB (스레드 로컬 할당 버퍼)

GC튜닝

올드영역 객체최소화하기

Major GC시간 짧게

java -XX:+PrintCommandLineFlags -version
-XX:ConcGCThreads=3 -XX:G1ConcRefinementThreads=10 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=268435456 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=4294967296 -XX:MinHeapSize=6815736 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC 
openjdk version "18.0.2.1" 2022-08-18
OpenJDK Runtime Environment (build 18.0.2.1+1-1)
OpenJDK 64-Bit Server VM (build 18.0.2.1+1-1, mixed mode, sharing)

GC 종류 변화

Serial GC
Parallel GC
Parallel Old GC
CMS GC
G1

CMS GC : 메모리 단편화발생

G1 GC :메모리 단편화 해결

GC 알고리즘

자바 GC

자바 GC 실행 방법

Jim memory leak

Scouter

Riverbed

NPM

CMS에서는 compaction을 직접해줘야하나 ?

STW는 정확히 언제 발생하는가 ?

G1 에서는 STW가 특정 구간에만 발생할 수 있는 이유는 ?

https://mirinae312.github.io/develop/2018/06/04/jvm_gc.html

https://d2.naver.com/helloworld/329631

https://d2.naver.com/helloworld/1329

http://imp51.tistory.com/entry/G1-GC-Garbage-First-Garbage-Collector-Tuning https://thinkground.studio/%EC%9D%BC%EB%B0%98%EC%A0%81%EC%9D%B8-gc-%EB%82%B4%EC%9A%A9%EA%B3%BC-g1gc-garbage-first-garbage-collector-%EB%82%B4%EC%9A%A9/

static 변수는 JVM의 어디에 저장될까 ?

haileykim2014 — Sun, 25 Dec 2022 14:27:01 +0900

자바 키워드부터 다시 공부하고 있다.

static 사용의 장단점 및 주의사항을 알게되면서 JVM메모리에는 어떻게 저장될지 궁금해서 찾아보았다.

찾아볼수록 사람마다 다른 해석을 하고 Java8에서의 변화도 알게되면서 정리하는데 오랜 시간이 걸렸다.

(혹시 잘못 이해한 부분이 있다면 피드백 부탁드립니다.)

이해가 필요했던 부분들

static
JVM 의 method area
constant pool vs string constant pool
Permanent Generation의 변화

Static 변수가 heap에서 관리되다 ?

static키워드를 통해 정의된 변수들은 method area내 constant pool에 reference 정보가 들어가고 value는 heap에 들어가 GC대상이 된다. 특히 String을 static으로 선언하면 heap안에 String constant pool안에 value가 저장된다. new키워드없이 바로 문자열을 대입하면 string constant pool영역에서 하나의 객체로 유지되는 것이다.

이는 new 키워드를 이용했을때와 다르다. static String을 new연산자를 이용하면 heap안에서 계속 새로운 객체로 인식이된다.

method area를 heap의 일부로 정리되어있는 글도 있는데, 포인트는 Java8 부터 Static Oject 를 heap영역에 옮겨서 GC 대상이 될 수 있도록 한 것이다.

히스토리

이는 Permanent Generation이 MetaSpace으로 변한 히스토리 이해가 필요했다.

Class 데이터를 저장하는 곳은 method area이고 Java8이전에는 Method area를 PermGen에 할당했다. 이때 VM옵션으로 정해진 사이즈를 줬는데 이게 out of memory를 발생하게 했다. Java8 이후에는 PermGen 영역이 완전히 없어지고 Metaspace가 PermGen의 역할을 한다. permanent generation 에 저장된 정보도 GC대상이었다. 참조를 하지않는 Object를 GC대상이되록 하는데 변화가 있었던 것이다.

정리

지역변수가 primitive type 이면 stack에 저장된다.
지역변수가 reference type 이면 객체는 heap에 저장되고 객체를 가리키는 reference는 stack에 저장된다.
인스턴스 변수일 경우 primitive type 및 reference type 모두 객체는 heap에 저장되고 그 객체의 reference는 stack에 저장된다.
클래스 변수가 primitive type이면 method area 내 runtime constant pool에 reference가 저장되고 value가 heap에 저장된다.
클래스 변수가 reference type이면 heap내 객체자가 저장되고 reference를 method area내 runtime constant pool에 저장된다.
String Literal 은 Heap내 String constant pool에 저장되어 동일한 주소를 유지한다.

참고 블로그

https://jgrammer.tistory.com/144

https://stackoverflow.com/questions/50163218/is-method-area-still-present-in-java-8

https://mirinae312.github.io/develop/2018/06/04/jvm_memory.html

https://8iggy.tistory.com/230

JVM

haileykim2014 — Sat, 24 Dec 2022 03:38:46 +0900

JVM

실행될 클래스 파일을 메모리에 로드 후 초기화 작업 수행
메소드와 클래스변수들을 해당 메모리 영역에 배치
클래스 로드가 끝난 후 JVM은 main메소드를 찾아 지역변수, 객체변수, 참조변수를 스택에 쌓음
다음 라인을 진행하면서 상황에 맞는 작업 수행

JVM은 운영체제에 독립적

Java를 사용하려면 JDK를 설치해야하는데 JDK는 운영체제별로 종류가 다르다.

JDK안에는 JRE, API,JVM이 포함되어 있다.

운영체제마다 다른 JVM이 제공되어 독립적일 수 있다.

JVM 실행

자바 코드 (.java) 컴파일 -> 바이트 코드파일 생성(.class) -> 기계어 코드파일 변환 (JVM역할)

1. Class Loader

실행에 필요한 실행파일(.class)찾는다

- bootstrap classloader

- extension classloader

- application classloader

2. 바이트 코드 검증

클래스 로더가 모든 실행 파일을 준비하면 이 파일의 코드가 올바른지 검증한다.

3. 기계어 코드로 변환

Java실행 파일은 바이트 코드이기 때문에 실행될때 다시 한번 기계가 읽을 수 있는 형태로 인터프리터를 통해 해석된다.

- 인터프리터

- JIT 컴파일러

Runtime Data Area

런타임 데이터 영역에서
여러 쓰레드가 heap, method area ( + runtime constant pool)을 공유하고
각 쓰레드는 PC register , stack , Native method stack을 가진다.

1. Method area

JVM이 읽어 들인 클래스와 인터페이스에 대한 runtime constant pool, 멤버변수, 클래스 변수, 생성자와 메소드를 저장하는 공간

메서드 영역은 모든 스레드가 공유하는 영역으로 JVM이 시작될 때 생성된다. JVM이 읽어 들인 각각의 클래스와 인터페이스에 대한 런타임 상수 풀, 필드와 메서드 정보, Static 변수, 메서드의 바이트코드 등을 보관한다. 메서드 영역은 JVM 벤더마다 다양한 형태로 구현할 수 있으며, 오라클 핫스팟 JVM(HotSpot JVM)에서는 흔히 Permanent Area, 혹은 Permanent Generation(PermGen) 이라고 불렸는데 지금 Metaspace라고 불린다. 메서드 영역에 대한 가비지 컬렉션은 JVM 벤더의 선택 사항이다

- JVM시작시 생성

- 프로그램 종료시 까지

- 구성 방식이나 GC방법은 JVM벤더마다 다를 수 있다.

* runtime constant pool : 상수 풀은 특정 클래스의 코드를 실행하는 데 필요한 상수를 포함한다. 기본적으로 심볼 테이블과 유사한 런타임 데이터 구조이다. 자바 클래스 파일에서 클래스별 또는 인터페이스별 런타임을 표현한다. JVM은 클래스 파일을 로드하면서 이 constant_pool 정보를 메서드 영역의 런타임 상수 풀에 넣는다

클래스 파일 포맷에서 constant_pool 테이블에 해당하는 영역이다. 메서드 영역에 포함되는 영역이긴 하지만, JVM 동작에서 가장 핵심적인 역할을 수행하는 곳이기 때문에 JVM 명세에서도 따로 중요하게 기술한다. 각 클래스와 인터페이스의 상수뿐만 아니라, 메서드와 필드에 대한 모든 레퍼런스까지 담고 있는 테이블이다. 즉, 어떤 메서드나 필드를 참조할 때 JVM은 런타임 상수 풀을 통해 해당 메서드나 필드의 실제 메모리상 주소를 찾아서 참조한다.

2. Heap area

런타임시 동적으로 할당하여 사용하는 영역이다

new연산자로 생성된 객체와 배열을 저장한다.

참조하는 변수나 필드가 없다면 의미없는 객체가되어 GC대상이 된다.

3.Stack area

JVM 스택안에 스택프레임 구조를 저장한다.

각 스레드 마다 존재한다.

메소드 호출시 프레임을 추가하고 메소드가 종료되면 프레임제거하는 동작을 수행한다.

후입선출

primitive 타입변수는 스택영역에 직접 값을 가진다.

JVM 스택은 각 스레드마다 하나씩 존재하며 스레드가 시작될 때 생성된다. 스택 프레임(Stack Frame)이라는 구조체를 저장하는 스택으로, JVM은 오직 JVM 스택에 스택 프레임을 추가하고(push) 제거하는(pop) 동작만 수행한다. 예외 발생 시 printStackTrace() 등의 메서드로 보여주는 Stack Trace의 각 라인은 하나의 스택 프레임을 표현한다

5. PC register

스레드가 생성될때 마다 생기는 공간이다.

스레드가 어떠한 명령을 실행하게 될지에 대한 부분을 기록한다.

6. Native method stack area

자바 외 언어로 작성된 네이티브 코드를 위한 영역이다.

참고

https://docs.oracle.com/javase/9/docs/api/java/lang/management/MemoryMXBean.html

https://goneoneill.tistory.com/43

Java - static 사용의 지양

haileykim2014 — Sat, 17 Dec 2022 23:07:53 +0900

static : global state

static 변수는 코드 여러 부분에서 영향을 받을 수 있어 변화를 추적하기가 어렵다.

1. static은 객체 지향 적이지 않다.

각 객체들의 데이터들이 캡슐화 되어야한다는 객체지향의 원칙에 위배된다.

예를 들어 static변수를 공유하여 여러 프로그램에서 사용할때 서로의 상태에 영향을 줄 수 있다. (데이터 정합성 문제 발생)

오버라이딩이 불가능하다.

메모리 회수가 어렵다 -> 가상머진의 메모리 부족

2. 객체의 라이프 타임

static변수는 프로그램이 실행되고 있는 내내 살아있게 된다. 그 클래스 작업이 끝났더라도 static변수가 점유하고 있는 메모리는 garbage collector에 의해 회수되지 않는다.반대로 그 변수를 인스턴스화 해서 main()함수에서 하나의 인스턴스로 생성하고, 그 인스턴스에게 함수 호출을 시키고 그 함수 호출이 끝나면 인스턴스를 소멸된다.

static은 재사용성이 떨어진다.

원본 :

http://tech.thegajago.com/2016/02/20/%EC%99%9C-%EC%9E%90%EB%B0%94%EC%97%90%EC%84%9C-static%EC%9D%98-%EC%82%AC%EC%9A%A9%EC%9D%84-%EC%A7%80%EC%96%91%ED%95%B4%EC%95%BC-%ED%95%98%EB%8A%94%EA%B0%80/