eventHandling

• react의 component는 상태를 가지고, 상태의 변화에 따라 컴포넌트가 리 랜더링됨
  • 즉, 리엑트 컴포넌트의 상태를 변경시키는 무언가가 있다.
    • 그 무언거의 대부분이 바로 이벤트
• javaScript의 event와 약간차이는 있으나 비슷하다.
  • react도 결국 javaScript다.
• JSX에선 카멜케이스로 구성된 속성에 이벤트 함수를 넣는다.

  • <button onClick={handleClick}>Button </buttonn>

• react의 이벤트에선 이벤트함수가 호출되면 인자로 SyntheticEvent 객체가 전달됨
  • SyntheticEvent는 javascript의 event 객체를 래핑한 객체임.
  • 거의 유사한 인터페이스를 가지고 있음
  • 원본 이벤트 객체도 접근 가능 SyntheticEvent.nativeEvent

eventHandler함수를 만들때는 react lifecycle을 고려해야한다.

• 컴포넌트 내부에서 함수를 만들면 리랜더링 될때마다 새로 함수가 쓰여진다.
  • 이게 필요한 순간도 있겠으나 아닌 순간도 있다.
  • 새로 함수를 쓸 필요가 없다면 컴포넌트 외부에서 이벤트 핸들러 함수를 만들자.
  • 또는 useCallback으로 감싸주면 리랜더링을 피할 수 있다.

import { useCallback } from "react";

// 컴포넌트 외부에 함수 선언
function handleClickOutOfComponent(e) {
  console.log("click2", e);
}

function App() {
  // 컴포넌트 내부의 함수 
  function handleClick(e) {
    console.log("click1", e);
  }
  const handleChange = useCallback((e) => {
    console.log("change", e.target.value);
  }, []);

  return (
    <div>
      <button onClick={handleClick}>Button1</button>
      <button onClick={handleClickOutOfComponent}>Button2</button>
      <div>
        <input type="text" onChange={handleChange} />
      </div>
    </div>
  );
}
export default App;

이벤트의 종류

Mouse event

• onClick : 마우스 클릭 (down + up )
• onMouseDown : 버튼 누를시
• onnMouseUp : 버튼 뗄시
• onMouseEnter : 요소 밖에서 안으로 마우스 커서가 들어감
• onMouseLeave : 요소 안에서 밖으로 마우스 커서가 나감
• onMouseMove : 요소 안에서 마우스 커서가 움직임

Keyboard event

• onKeyDown : 키를 눌렀을때 (물리적인 키에 반응)
• onKeyUp : 키를 떼었을때
• onKeyPress : 키를 눌러서 문자가 입력될때(눌린 문자에 반응함)

Focus, Form event

• Focus
  • onFocus : 요소가 포커스 될때
  • onBlur : 요소의 포커스가 사라질경우
• Form
  • onChange : 요소의 값이 변경될때

그외

• 필요할때마자 찾아가면서 사용하도록하자.

Form 요소 컨트롤

• Form 요소를 컨트롤할때는 이벤트를 자주 사용한다.

Controlled Component

• 제어 컴포넌트 라고도 함.
• React에 의해 입력 요소 값이 제어되는 컴포넌트

import { useState } from 'react';

function TextArea() {
  const [textAreaVal, setTextAreaVal] = useState('');

  console.log('[TextArea] render', value);

  return (
    <textarea
      value={textAreaVal}
      onChange={(e) => {
        setTextAreaVal(e.target.value);
      }}
    />
  );
}

export default TextArea;

• 위 코드에서 textArea는 value 속성에 textAreaVal 스테이트 값을 넣어줌
• onChange 에서는 setTextAreaVal를 호출함
• 유저가 값을 입력하면 state에 유저의 입력이 반영 되면서 상태가 업데이트됨

장점

• 컴포넌트의 state 와 input value가 완전히 동일함(신뢰가능한 단일 출처)
• 다른 컴포넌트에 input value를 전달하거나 다른 이벤트 핸들러에서값을 재설정 할 수 있음

단점

• 값이 변경되는 매 순간 렌더링이 됨
• 컴포넌트의 영향 범위가 클수록 성능 저하됨

Uncontrolled Component

• Controlled Component와는 반대로 input value를 컴포넌트 State에 연결하지 않고 사용하는 컴포넌트
• 값은 dom을 통해 가져온다.
  • ex: document.querySelector('#{id}').value
• useRef를 사용해 가져올 수 도 있다.
  • useRef는 Hooks의 한 종류. 특정 요소의 레퍼런스를 직접 가져올때 사용
  • 연결된 값이 변경되더라도 리랜더링이 되지 않는다.

import { useRef } from 'react';

function UncontrolledTextInput() {
  const inputRef = useRef(); //1. useRef를 이용해 ref를 만든다.

  console.log('[UncontrolledTextInput] render');

  return (
    <>
    /* jsx에서 ref속성에 연결한다.  */
      <input ref={inputRef} type="text" id="input" />
      <button
        onClick={() => {
          console.log(inputRef.current.value);
        }}
      >
        Get value
      </button>
    </>
  );
}

export default UncontrolledTextInput;

Hooks

• react의 life cycle을 알려면 Hooks를 알 필요가 있다.
• Hooks에 대해 알아보자.

Hooks의 종류

• useState
• useEffect
• useCallback
• useMemeo, useContext, useRef, useLayoutEffect
• 위와 같이 10개 정도가 있는데, 그중 상위 3개정도가 주로 사용된다. 나머지는 필요할때 찾아서 쓰면된다.

useState

• component의 State를 생성하는 Hook

  const [value, setValue] = useState(0) //인자는 초기값
  // 첫번째 요소(value) => state 값
  // 두번째 요소(setValue) => state를 set 해주는 setter 함수

useEffect

• component가 랜더링 될때 현재 상태 변화에 따라 조건적으로 특정 작업을 실행하기 위한 Hook
  • 처음 랜더링 될때
  • 컴포넌트가 언마운트 될때
    • cleanup 함수를 이용해서 component unmount시 자원, 이벤트 등을 정리해준다.

      useEffect(() => {
      ...
      return () => {
      ... // cleanup 함수. component 가 unmount될때 실행됨
      }
      },[])

• 상태가 변할때
  • useEffect()함수에 인자로 상태 변화를 감지할 state를 배열로 전달한다.
  • 이 경우 클린업 함수는 상태 변화를 감지하고 useEffect를 재실행하기 직전에 실행됨.

    const [value, setValue] = useState(0) 
    useEffect(() => {
    ...
    return () => {
    ... // cleanup 함수. component 가 unmount될때 실행됨
    }
    }, [value])

useCallback

• 리 랜더링 시 기존에 만든 함수를 재생성 하지 않고 재활 용 하기 위해 사용하는 Hooks
• memoization

const fooFun =useCallback(()=>{
  console.log("bar");
})

Hooks 사용시 주의사항

• 조건적으로 사용하면 안된다.
• Hooks 는 React Component에서만 사용 가능하다.

React의 렌더링 과정

Rerendering

• Component의 상태(state, props)가 변경 되면서 해당 컴포넌트를 다시 실행하여 화면에 그린다는 의미.
• Rerendering시 매번 다른 동작을 하게되고 이를 우리는 life cycle이라고함

React의 Life Cycle

• Class형 과 Function형이 약간 다름
• Class
  1. constructor 실행
     • 최초 실행
       1. getDerivedStateFromProps() 실행 : props로 넘어온 값을 state와 동기화하는 메소드
       2. render method 실행 : 화면에 그릴 JSX를 반환
       3. componentDidMount() 실
     • 업데이트 시
       1. getDerivedStateFromProps()
       2. shouldComponentUpdate() 실행 : 현재 일어난 상태변화를 확인하여 컴포넌트를 다시 랜더링 할지 말지를 결정
       3. componentDidUpdate()
     • 컴포넌트 삭제시
       1. 제거
       2. componentWillUnmount()실행
• function형
  • 최초 실행
    1. 자기자신을 실행하여 JSX를 리턴하고 DOM에 반영
    2. useEffect Hook 실행: componentDidMount, componentDidUnMount, componentDidUpdate()를 커버해줌.
  • 업데이트시
    1. 자기 자신 실행 후 JSX반한
    2. useEffect 실행
  • unmount 시
    1. useEffect만 실행

Component

• 스스로 상태를 관리하는 캡슐화된 코드 조각
• 컴포넌트는 하나의 JSX를 반환하는 함수.

  function App(){  
  return (
    <h1> Hello </h1>
    <h1> World </h1>
   )  
  }

  ReactDom.render(
    document.getElementById('root')  
  )

위 코드에서 App() 함수가 컴포넌트. div 태크로만들어진 JSX를 반환한다.
ReactDom이 render 메소드를 이용해서 화면에 그린다.

JSX로 컴포넌트를 만드는것과 함수형태로 컴포넌트를 만드는 방식의차이

1. 컴포넌트는 기본적으로 함수이기 때문에 자신만에 고유한 로직이 들거갈 수 있다.
2. 스스로 상태를 가질 수 있다.

컴포넌트 생성시 주의사항

• 컴포넌트 이름은 PascalCase
  • MyComponent
  • ArticlePage
  • UserProfile
• 컴포넌트는 의미 단위로 쪼개서 파일을 분리한다.
  • header, content, footer ...
  • 각 컴포넌트가 역할을 가지도록한다.
• 최 상위 컴포넌트는 일반적으로 App이다.
• App컴포넌트를 ReactDom.render() 를 이용해서 랜더링 하는 코드는 일반적으로 index.js에 넣는다.
• index.js 는 모든 컴포넌트의 엔트리 포인트, App.js는 모든 컴포넌트의 root 컴포넌드

Props

• 프로퍼티의 줄임말.
• 컴포넌트에서 하위 컴포넌트로 어떤 값을 전달해줄때 사용하는 요소

function App() { 
  return( 
    <div> <MyComponent value={'test'} /> </div> 
  ) 
} 

function MyComponent(props) { 
  return <div>{props.value} </div> 
}

• App Component가 하위 컴포넌트인 MyComponent로 데이터를 전달해줌.
• 전달반은 데이터는 object형태이며, 전달 했던 속성 이름으로 접근해서 사용할 수 있음.

    function App() { 
    return(
     <div>
       <MyComponent>
         <h1> value </h1> 
       </MyComponent>
     </div>
    )
    }


  function MyComponent(props) {  
    return
      {props.children}
    }

• 상위 컴포넌트가 값을 감싸는 형태로 전달도 가능. 이때는 props에서 children을 이용해서 접근
• 이때 children으로 전달받은 데이터는 <h1> 태그로 이루어진 JSX 값이다.

Props 활용팁.

• 구조분해 할당을 잘 활용한다.
• 특정 Props에 기본 값을 줄 수 있다.(defaultProps).
• Props는 읽기 전용.

State

• 컴포넌트 내부에서 사용되는 변수
  • state 값이 변하면 컴포넌트가 리렌더링됨.
  • 렌더링 사이클에서 값이 보존됨

function App(){ 
  const[value, setValue] = useState(); 
  return ( 
    <div> {value} </div>
  ) 
}

• useState를 사용하면 value와 setValue를 리턴해준다.
• setValue를 이용하면 value를 set할 수 있으며 이때 리 랜더링이 실행됨
• value가 set 되는 시점은 리렌더링이 된 이후라는점에 주의해야함.

Hooks

• 클래스형 컴포넌트의 단점을 보완하기 위해 함수형 컴포넌트에 지급된 개념
• 지금까지는 함수형 컴포넌트를 사용했다.
• 하지만 클래스형 컴포넌트라는 방식도 있다.
  • 과거에 useState 같은 Hooks는 이용할 수 없었기때문에 클래스형 컴포넌트를 이용했다.
  • 클래스형은 몇가지 안좋은점이 있어서 점점 안쓰게 되었다.

JSX란?

• Javascript 확장 문법으로 Javascript XML이란 의미.

• 리엑트에서는 JSX를 이용하여 화면(컴포넌트)을 표시함.

  • 리엑트가 JSX -> HTML을 만들어줌

  JSX의 특징

  • JSX에서 사용되는 태그의 속성 이름이 HTML과 약간 다름
    • class => className
    • for => htmlFor
    • onclick => onClick
  • 태그를 명시적으로 닫아줘야함.

        //잘못된 JSX
        <button class="btn"> hello, world </button>
        <input type="text"> 

        //옳게된 JSX\`\`\` - 하나의 태그로 감싸져 있어야함.
        <div>
          <button className="btn"> hello, world </button>
          <input type="text"/> 
        </div>

JSX에서 Javascript사용하기

1. 중괄호 {} 안에서 JavaScript 표현식 사용

JSX 안에서는 중괄호 **`` 안에 JavaScript 표현식**을 사용할 수 있습니다.

const name = "Alice";

return <h1>Hello, {name}!</h1>;

• ✅ 사용 가능한 것: 변수, 함수 호출, 삼항 연산자 등 표현식(expression)
• ❌ 사용 불가: if, for 같은 문장(statement)

2. 조건부 렌더링

2-1. 삼항 연산자

const isLoggedIn = true;

return <div>{isLoggedIn ? "Welcome!" : "Please log in."}</div>;

2-2. 논리 AND (&&)

const hasMessages = true;

return <div>{hasMessages && <p>You have new messages.</p>}</div>;

3. 리스트 렌더링 (map 사용)

const items = ["Apple", "Banana", "Orange"];

return (
  <ul>
    {items.map((item, index) => (
      <li key={index}>{item}</li>
    ))}
  </ul>
);

• key 속성은 필수는 아니지만 React가 효율적으로 렌더링하기 위해 사용합니다.

4. 반복문 사용하기 (for, while 등)

JSX 안에서는 for, while 같은 문장(statement) 은 직접 사용할 수 없습니다. 대신 반복문은 JSX 바깥에서 데이터를 처리한 뒤 JSX에서는 map() 등으로 표현식 형태로 렌더링합니다.

const items = ["Apple", "Banana", "Orange"];
const elements = [];

for (let i = 0; i < items.length; i++) {
  elements.push(<li key={i}>{items[i]}</li>);
}

return <ul>{elements}</ul>;

• 또는 map() 사용이 가장 권장되는 방식입니다 (위의 리스트 렌더링 참고).

5. 함수 호출

function formatName(user) {
  return `${user.firstName} ${user.lastName}`;
}

const user = { firstName: "John", lastName: "Doe" };

return <h1>Hello, {formatName(user)}!</h1>;

6. 속성(prop)에도 JavaScript 표현식 사용 가능

const isDisabled = true;

return <button disabled={isDisabled}>Click me</button>;

7. 스타일 객체도 JavaScript로 정의 가능

const style = {
  color: "blue",
  fontSize: 20
};

return <p style={style}>Styled Text</p>;

• CSS 속성 이름은 camelCase로 써야 합니다 (font-size → fontSize)

JVM의 Garbage Collection(GC)

• Garbage Collection(GC)은 JVM(Java Virtual Machine)에서 동정으로 생성된 객체의 메모리를 자동으로 관리하는 메커니즘. GC는 애플리케이션의 메모리 누수를 방지하고, 더 이상 사용되지 않는 객체를 제거해 메모리를 효율적으로 사용하도록한다.

기본개념

1. GC의 역할

• JVM이 힙 메모리(Heap Memory)에 생성된 객체 중 더 이상 사용되지 않는 객체를 식별하고 제거한다.
• 이를 통해 애플리케이션의 메모리 누수를 방지하고, 수동 메모리 관리의 필요성을 제거한다.

2. GC가 관리하는 영역

• Heap Memory
  • Youg Generation (Eden, Survivor Space)
  • Old Generation (Tenured)
• Metaspace
  • 클래스 메타데이터를 저장하는 공간.

JVM Heap Memory 구조

1. Young Generation

• 새로 생성된 객체가 저장됨.
• 크기가 작고, 객체의 생존 시간이 짧은 경우가 대부분.
• 구성요소
  • Eden Space: 새로운 객체가 처음 생성되는 공간.
  • Survivor Space: Eden에서 살아남은 객체가 복사되는 공간.

2. Old Generation

• Young Generation에서 오래 살아남은 객체가 이동.
• 크기가 크거나 생존 시간이 긴 객체가 저장됨.

3. Metaspace

• 클레스 로더와 메타데이터 정보를 저장.

GC 동작 과정

1. Minor GC

• Young Generation에서 발생.
• 동작 원리
  1. Eden에서 객체가 생성.
  2. Eden이 가득차면 Minor GC가 실행
  3. Eden에서 살아남은 객체가 Survivor Space로 이동.
  4. 여러번의 Minor Gc를 통해 Survivor Space에서 생존한 객체가 Old Generation으로 이동.
• 특징
  • 실행 속도가 빠르며, Young Generation 크기에 다라 성능이 좌우됨.
  • Stop-The-World 발생

2. Major GC(Full GC)

• Old Generation에서 발생
• 동작 원리
  1. Old Generation이 가득 차면 실행
  2. 사용되지 않는 객체를 제거하고 힙 메모리를 정리
• 특징
  • 실행 시간이 길고 Stop-The-Wold가 발생
  • Minor GC보다 성능에 더 큰 영향을 미침.

3. GC의 실행 과정(가비지 식별, 처리 과정)

• Mark: GC는 모든 객체를 순회하며 현재 참조되고 있는 객체를 식별하고 마크 함
• Sweep: 마크되지 않은, 즉 참조되지 않는 객체를 메모리에서 제거함.
• Compact(압축): 객체를 제거하고 남은 메모리 조각들을 모아 연속된 공간을 확보함. 힙메모리 단편화를 해소하는데 도움을 줌.

GC의 종류

JVM은 다양한 GC 알고리즘을 제공한다. 각각의 알고리즘은 GC성능과 애플리케이션 요구사항에 따라 다르다.

1. Serial GC

• 단일 스레드에서 작동
• 특징
  • 작은 애플리케이션(싱글 스레드)에 적합.
  • Full GC중 애플리케이션이 멈추는 "Stop-The-Wold"시간이 길다.

2. Parallel Gc(Throughput GC)

• 여러 스레드를 사용해 GC를 수행
• 특징
  • 처리량(Throughput) 지향.
  • 적절한 애플리케이션 성능과 낮은 GC비용을 제공.

3.G1 GC

• Java 9 이후의 기본 GC
• 특징
  • 힙을 Region으로 나누어 관리.
  • Yong/Old Generation을 따로 구분하지 않고 필요에 따라 Region을 재배치.
  • 짧은 응답 시간과 적은 Stop-The-World 시간을 제공.

4. ZGC

• 매우 낮은 지연시간을 목표로 설계
• 특징
  • 대규모 힙을 지원 (최대 16TB)
  • 애플리케이션 중단 시간이 10ms 이내

5. Shenandoah GC

• 낮은 지연시간을 제공.
• 특징
  • GC 작업과 애플리케이션 작업을 병렬로 수행.
  • ZGC 보다 짧은 지연시간 제공.

GC 튜닝과 모니터링

1. JVM옵선을 통한 설정

1. GC 종류 선택
   • -XX:+Use{GCNAME}
   • ex: G1GC -XX:+UseG1GC
2. Heap 크기 설정
   • Xms: 초기 힙 크기 (ex: Xms512m)
   • Xmx: 최대 힙 크기 (ex: Xmx1024m)
3. GC로그 활성화
   • -Xlog:gc

2. 주요 GC메트릭 모니터링

• GC 횟수와 시간: 애플리케이션 성능에 얼마나 영향을 주는지 확인.
• 힙 사용량: Minor GC및 Major GC 후의 메모리 상태
• 툴 사용: VisualVM, JConsole, Prometheus && Grafana

3.최적화를 위한 설정

1. 적절한 Heap크기 설정
   • 너무 작은 힙 크기는 잦은 GC유발
   • 너무 큰 힙 크기는 GC시간이 오래걸림
2. 객체 생명 주기 관리
   • 불필요한 객체 생성 줄이기
   • 전역 변수 사용 최소화
3. GC 로그를 통한 분석
   • GC로그를 주기적으로 분석 하여 병목현상을 파악.
   • 애플리케이션 패턴에 따라 GC알고리즘 선택
4. 메모리 누수 감지
   • 정적 코드 분석 툴을 사용하여 메모리 누수 방지.

JVM 메모리 구조에 대해 설명해보자

• JVM 메모리 구조는 JVM에서 프로그램이 실행될 때 데이터를 효율적으로 관리하기 위해 나누어진 영억이다. 각 영역은 특정한 역할과 특징을 가지마 애플리케이션의 안정적 실행을 보장한다.

1. Method Area

• 메소드 영역은 클래스와 관련된 메타데이터, 즉 프로그램의 구조적 정보를 저장하는 영역이다.
• JVM이 실행되는 동안 공유 메모리 영역으로 사용된다.
• 저장 내용
  • 클래스 메타데이터: 클래스 이름, 부모 클래스 정보, 인터페이스, 메소드, 필드 등.
  • Static 변수: 클래스 로드 시 초기화되는 정적 변수.
  • Constant Pool(상수 풀): 문자열 상수나 메소드/필드 참조와 같은 상수 정보를 저장.
  • 바이트코드: 각 메소드의 실제 실행 코드.
• 특징
  • 모든 Thread에서 공유함.
  • JVM이 시작될 때 초기화되고, 종료될 때까지 유지된다.

  ---

2. Heap Area

• 객체와 배열이 동적으로 생성되고 저장되는 메모리 영역.
• JVM에서 가장 큰 메모리 영역. Garbage Collector에 의해 관리됨.
• 저장 내용
  • 객체: new 키워드로 생성된 객체.
  • 인스턴스 변수: 객체가 가지고 있는 멤버 변수.
  • 클래스읜 런타임 데이터
• 구조
  • 힙은 크게 Young Generation 과 Old Generation 으로 나뉜다.
    1. Young Generation
       • 새로 생성된 객체가 저장되는 영역.
    2. Old Generation
       • Young Generation에서 오래 살아남은 객체가 이동됨.
       • 메모리에서 가장 크고, 주로 긴 생명주기를 가진 객체가 저장됨.
    3. Metaspace(Optional)
       • Java 8 이후 부터 클래스 메타데이터를 관리하는 메모리 공간.
• 특징
  • 모든 Thread에서 공유함.
  • 메모리가 부족하면 Garbage Collection이 실행됨

3.Stack Area

• 각 쓰레드마다 독립적으로 생성되는 메모리 영역, 메소드 호출과 관련된 데이터를 관리함.
• 저장 내용
  • Stack Frame: 메소드 호출 시마다 생성되는 단위.
    • 지역변수: 메소드 내에서 선언된 변수.
    • 매개변수: 메소드 호출 시 전달된 값.
    • 연산 중간 값: 연산 결과 저장.
• 구조
  • LIFO(Last In, First Out)로 작동
  • 메소드 호출 시 스택 프레임 생성 -> 메소드 종료 시 제거.
• 특징
  • 각 Thread 마다 독립적으로 생성.
  • 메모리 할당과 해제가 빠름.

4.PC Register

• 현재 실행 중인 명령어의 조소를 저장하는 메모리 영역
• JVM의 모든 명령은 순차적으로 실행되기 때문에 이 정보가 필요함
• 저장 내용
  • 명령어 주소 : 현재 실행중인 JVM 명령어의 메모리 위치
• 특징
  • 각 Thread 마다 독립적으로 생성
  • Java code 와 Native code 모두에 적용됨.

5. Native Method Stack

• Java 코드가 아닌, JVM 이 실행하는 네이티브 코드(C, C++)와 관련된 메모리를 관리.
• JNI(Java Native Interface)를 통해 호출되는 네이티브 메소드에서 사용.
• 저장 내용
  • 네이티브 메소드의 호출 정보와 실행에 필요한 데이터.
• 특징
  • 각 쓰레드마다 독립적으로 생성

정리

1. Method Area: 클래스 메타데이터, static 변수 저장
2. Heap Area: 객체와 인스턴스 변수 저장
3. Stack Area: 메소드 호출과 관련된 데이터 저장
4. PC Register: 현재 실행중인 명령어의 주소 저장.
5. Native Mtehod Stack: 네이티브 코드 실행과 관련된 메모리.

@Transactional 메소드 내에서 @Transactional(propagation = Propagation.REQUIRED_NEW) 메소드를 실행하게되면 어떤 일이 발생할까

트랜잭셔널 메소드에서 새로운 트랜잭션을 시작하면 어떤일이 발생하는지 알아보자.

1. 애플리케이션 시작 시 작업

1-1. 트랜잭션 관리자 등록

• 애플리케이션 시작 시 트랜잭션 관리자가 등록된다.
• 트랜잭션 전파 정책(Propagation)을 처리할 수 있도록 AOP 프록시가 생성된다.

1-2. AOP 프록시 생성

• @Transactional이 적용된 메소드에 대해 프록시가 생성된다.
• 각각의 메소드가 호출될 때 전파 정책을 해석하도록 설정된다.

2. 부모 매소드 실행(@Transactional, REQUIRED 전파 정책)

2-1. 트랜잭션 시작

• 부모 메소드가 호출되면 프록시가 트랜잭션 관리자를 통해 트랜잭션을 시작
• 트랜잭션 전파 정책 Propagation.REQUEIRED의 기본 동작에 따라 기존 트랜잭션이 없으면 새 트랜잭션을 시작.
• 데이터베이스 연결이 확보되고, auto-commit이 비활성화됨

2-2. 비지니스 로직 실행 중 자식 메소드 호출

• 부모 메소드 내에서 Propagation.REQUIRED_NEW가 적용된 자식 메소드가 호출됨.

3.자식 메소드 실행(@Transactional, Propagation.REQUIRED_NEW)

3-1. 부모 트랜잭션 일시 중단

• 자식 메소드가 호출되면 부모 트랜잭션이 일시중단 상태로 변경됨.
• 일시 중단된 트랜잭션은 컨텍스트에 보관되며, 자식 메소드가 끝날때까지 대기.

3-2. 새로운 트랜잭션 시작

• 자식 메소드는 항상 별도의 트랜잭션에서 실행
  • 트랜잭션 관리자가 새로운 데이터베이스 연결을 확보하거나 기존 연결을 재사용 하여 별도 트랜잭션을 시작.
  • 새로운 트랜잭션은 부모 트랜잭션과 독립적으로 커밋 또는 롤백될 수 있다.

3-3. 비지니스 로직 실행

• 자식 메소드의 비지니스 로직이 새로운 트랜잭션 내에서 실행됨.
• 데이터베이스 작업은 자식 트랜잭션의 컨텍스트에서만 적용됨.

3-4. 자식메소드 종료

• 자식 메소드 실행이 끝나면 아래와 같은 동작 발생
  • 정상종료시, 커밋
  • 예외 발생시 자식 트랜잭션롤백

4. 부모 메소드 재개

4-1. 부모 트랜잭션 복구

• 자식 메소드 실행이 끝난 후, 무보 트랜잭션이 일시중단 상태에서 복구됨.
• 부모 트랜잭션은 자식 트랜잭션과는 독립적으로 계속 진행됨.

4-2. 부모 메소드 비지니스 로직 실행(남은 작업)

• 부모 메소드의 나머지 비지니스 로직 실행.
• 데이터베이스 작업은 부모 트랜잭션 컨텍스트에 반영.

4-3 부모 메소드 종료

• 부모 메소드 종료되면 아래와 같은 동작 발생
  • 정상 종료시 커밋
  • 예외 발생시 부모 트랜잭션 롤백

5. 특이 케이스

5-1. 자식 트랜잭션 커밋 후 부모 트랜잭션 롤백

• 부모 트랜잭션이 나중에 롤백 되더라도 자신 트랜잭션은 독립적으로 커밋 되었기 때문에 영향을 받지 않는다.

5-2. 자식 트랜잭션 롤백 후 부모 트랜잭션 정상 종료

• 자식 트랜잭션이 실패하면 부모 트랜잭션은 이를 감지할 수 없다.
  • 단, 예외를 명시적으로 처리한다면 감지시킬 수 있다.
  • 부모 트랜잭션은 독립적으로 커밋 또는 롤백된다.

정리:

1. 부모 메소드(@Transactional, Propagation.REQUIRED)가 호출되며 트랜잭션이 시작됨.
2. 자식 메소드(@Transactional, Propagation.REQUIRED_NEW)가 호출되면 부모 트랜잭션 일시중단.
3. 자식 메소드는 새로운 트랜잭션에서 실행되며 독립적으로 커밋 또는 롤백됨
4. 자식 메소드 실행 후, 부모 트랜잭션이 북구되어 남은 로직 실행
5. 자식과 부모 트랜잭션은 서로 독립정이며, 서로의 성공 여부에 영향을 주지 않음.

이런 구조로 트랜잭션간의 독립성이 보장되며, 필요 시점에 새로운 트랜잭션을 생성해 데이터 무결성을 관리하는데 도움이 된다.

@Transactional 어노테이션이 있는메소드, 스프링 시작부터 메소드 시작까지의 작업

@Transactional 어노테이션이 있는 메소드가 실행될때 어떤 일이 일아날까.
스프링 시작부터 메소드가 실행되고 종료될때까지 어떤일 일어나는지 알아보자.

1.어플리케이션 시작시 작업

1-1.트랜잭션 관리자 등록

• Spring Boot는 자동 설정(Auto Configuration)을 통해 적절한 트랜잭션 관리자를 등록한다.
  • 에를들어, JPA를 사용하는 경우 JpaTransactionManager를 기본으로 등록한다.
• 이 관리자는 트랜잭션의 시작, 커밋, 롤백 등을 담당함.

1-2.AOP 프록시 생성

• @EnableTransactionManagement 또는 자동 설정에 의애 트랜잭션 메소드가 AOP프록시로 감싸진다.
• 스프링은 빈 스캐닝 중 @Transactional이 붙은 메소드를 확인하고, 해당 메소드가 실행될 때 트랜잭션 관리가 적용되도록 프록시 객체를 생성한다.
  • 기본적으로 CGLIB 또는 JDK 동적 프록시를 사용한다.

2.메소드 실행 시 작업

2-1.프록시를 통한 메소드 호출

• 트랜잭션 메소드를 호출하면 실제 메소드를 실행하기 전에 프록시 객체가 인터셉트한다.
• 프록시는 트랜잭션 설정과 관리작업을 수행한 후 실제 메소드를 호출한다.

2-2.트랜잭션 동작 정의 확인

• 프록시는 메소드에 선언된 @Transactional 속성을 확인한다.
  • 트랜잭션 전파(Porpagation)
  • 격리수준(Isolation Level)
  • 읽기 전용(Read-only)
  • Timeout
  • 롤백 정책(Rollback Rules)

2-3.트랜잭션 시작

• 트랜잭션 관리자는 트랜잭션을 시작한다.
  • 트랜잭션 전파 전책에 따라 새 트랜잭션을 생성하거나 기존 트랜잭션에 참여한다.
• 데이터베이스 커넥션을 확보하고(필요시), auto-commit이 비 활성화 된다.

3.실제 메소드 실행

3-1.비지니스 로직 실행

• 트랜잭션 컨텍스트 내에서 실제 메소드가 실행됨.
• 데이터베이스의 CRUD 작업이 발생하면, 변경 사항은 트랜잭션 컨텍스트 내에 보류됨

3-2.예외 처리

• 메소드 실행 중 예외가 발생하면, 프록시는 롤백 정책을 참조하여 트랜잭션 롤백 여부를 결정.
  • 기본적으로 RuntimeException 과 Error 가 발생하면 롤백됨.
  • checked exception은 명시적으로 롤백 설정이 없으면 커밋됨.

4.메소드 실행 완료 후 작업

4-1. 트랜잭션 커밋 또는 롤백

• 메소드 실행이 성공적으로 끝나면 트랜잭션 관리자는 트랜잭션을 커밋한다.
  • 데이터베이스 변경 사항이 확정되고, 커넥션이 반환된다.
• 예외가 발생한 경우 롤백 작업이 수행된다.
  • 변경된 데이터는 폐기되며, 트랜잭션이 중단됨.

4-2.리소스 정리

• 트랜잭션이 종료되면 사용된 데이터베이스 커넥션 및 기타 리소스가 pool로 반환된다.
• 트랜잭션 컨텍스트와 관련된 쓰레드 로컬 데이터가 정리된다.

5.애플리케이션 종료 시 작업

• 트랜잭션 관리자는 애플리케이션 종료 시 등록된 리소스를 정리하며, 사용중인 데이터베이스 연결이나 트랜잭션 관련 매니저를 닫는다.

정리

1. 애플리케이션 시작 : 트랜잭션 관리자 설정, AOP프록시 생성
2. 메소드 호출시 :
   • 프록시가 트랜잭션을 시작, 트랜잭션 속성 확인
   • 메소드를 실행하며 예외 여부에 따라 커밋 또를 롤백을 결정
3. 메소드 실행 후 : 트랜잭션이 종료되고 리소스 반환
4. 애플리케이션 종료시 : 트랜잭션 관련 리소스 정리

스프링 부트 어플리케이션이 실행되면 어떤 일들이 일어나는가.

Spring Boot Application이 시직되면 내부에서 일어나는 일에 대해 정리한다.

1.JVM 및 Main 메서드 시작

• JVM 이 애플리케이션을 실행하며 main메서드를 호출
• Spring Boot 애플리케이션은 @SpringBootApplication 어노테이션이 붙은 클래스의 main메서드를 시작점으로 잡는다.

2.SpringApplication 초기화

• SpringApplication.run() 메서드가 호출되며 스프링 애플리케이션 컨텍스트가 초기화됨
• 주요 작업
  • 애플리케이션 타입 결정(Servlet, Reactive, None)
  • 배너 출력 여부 설정
  • 기본 프로퍼티 및 환경 로딩

3.Environment 생성 및 설정

• Environment 객체가 생성되어 시스템 속성, 환경 변수, 프로파일 등이로그됨
• 외부설정(ex: application.properties, application.yml)이 읽혀지고 환경 변수와 병합됨.

4.Application Context 생성

• Spring Boot 는 실행 모드에 따라 적절한 컨텍스트를 선택함.
  • AnnotationConfigServletWebserverApplictionContext (웹 어플리케이션)
  • AnnotationConfigReactiveWebServerApplicationContext (리액티브 어플리케이션)
  • AnnotationConfigApplictionContext (비 웹 어플리케이션)
• 이 컨택스트는 어플리케이션의 모든 빈(bean) 및 설정을 관리함

5.CommandLineRunner 및 ApplicationRunner등록

• ApplicationContext 초기화 중에 CommandLineRunner와 ApplicationRunner 인터페이스를 구현한 빈들이 등록됨
• 이 빈들은 애플리캐이션 초기화가 완료된 후 추가 작업을 실행할 수 있음.

6.자동설정(Auto Configuration)

• Spring Boot는 @EnableAutoConfiguration을 통해 여러 자동 설정 클래스(AutoConfiguration)을 활성화함.
• 자동 설정은 클래스 패스 및 환경 변수를 기반으로 애플리케이션에 필요한 빈을 자동으로 구성함.
  • Ex) DB Connection 설정, Web server 설정, Spring Security 설정 등

7.빈(Bean) 등록 및 DI(의존성 주입)

• 스프링 애플리캐이션 컨텍스트 내에서 모등 @Component, @Service. @Repository, @Controller 등의 빈을 스캔하여 등록
• 등록된 빈들 간의 의존성을 주입(생성자, 세터, 필드 기반)
• 프로파일 조건에 따라 특정 빈만 활성화될 수도 있음.

8.내장 웹서버 시작(Optional)

• 웹 어플리케이션인 경우, Spring Boot는 내장된 톰캣, 제티, 언더토우 등을 통해 HTTP서버를 시작
  • HTTP 포트, SSL설정 등이 적용됨.
• 서블릿 컨테이너가 초기화 되고 DispatcherSErvlet이 설정됨.

9.Spring MVC 또는 WebFlux 설정(웹 애플리케이션인경우)

• DispatcherServlet을 통해 요청을 처리하는 기본 매핑을 설정
• HandlerMapping,HandlerAdapter,ViewReolver등을 초기화 하여 웹 요청에 필요한 구성요소를 준비

10.이밴트 발행 및 리스너 실행

• Spring Boot는 애플리케이션 실행 과정에서 여러 이벤트를 발행함.
  • ApplicationStartingEvent
  • ApplicationEnvironmentPreparedEvent
  • ApplicationPreparedEvent
  • ApplicationStartedEvent
  • ApplicationReadyEvent
• 위 이벤트를 통해 특정 시점에 사용자 정의 작업을 실행할 수 있음.

11.애플리케이션 준비 완료

• 애플리케이션 컨택스트 초기화가 완료되고, 모든 빈이 생성되고 초기화됨
• CommandLineRunner 및 ApplicationRunner구현체가 실행됨.
• ApplicationReadyEvent 가 발행되며 애플리케이션이 요청을 처리할 준비가 완료됨

12.애플리케이션 실행 상태 유지

• Spring Boot는 실행 상태를 유지하며 HTTP요청을 대기하거나 비웹 애플리케이션에서는 작업을 지속함.
• 내부적으로 애플리케이션 컨택스트는 필요에 따라 라이프 사이클을 관리함.

13.애플리케이션 종료

• 애플리캐이션 종료시 Spring Boot는 ApplicationContext를 닫으며 빈의 destroy() 메서드 호출 및 리소스 정리를 수행
• ApplicationFailedEvent 가 발행될 경우 애플리케이션 시패를 기록

Spring Boot Application으 LifeCycle에 대해 간략하게 정리 해 보았다.
Spring 기반의 서비스를 운영 / 개발 하는 회사라면 자주 나오는 질문이니 숙지하고 있으면 좋다.
세부 내용까지는 힘들더라도 1~12번 넘버링 되어있는 순서만이라도 기억하면 좋다.

Jetbrain Blog의 번역 글입니다. 원본은 아래 주소에 접속하여 확인 해 주세요 
https://blog.jetbrains.com/kotlin/2023/11/kotlin-multiplatform-development-roadmap-for-2024/ 

Kotlin Multiplatform Development Roadmap for 2024

최근 완성된 코틀린 멀티플랫폼의 안정성 덕분에, 세계의 많은 개발팀들은 이제 장애물 없이 코플린 멀티 플랫폼을 프로덕션에 자신있게 적용할 수 있게 되었다.  하지만 이는 단지 KMP(Kotlin Multiplatform)과 에코시스템을 시작하는것일 뿐이다. 최고의 크로스 플랫폼 개발을 경험을 갖추게 하기 위해서, 2024년에 JetBrains는 핵심 코틀린 펄티플랫폼기술, 컴포즈 멀티 플랫폼, KMP도구와 라이브러리 같은 미래의 발전을 주도할것이다. 이 분야에서 무엇을 배워야하고, 어떤 순서로 배뭐야할지 알아보자. 

우리는 컴포즈 멀티플랫폼을 만들기 위해 헌신했다. 컴포즈 멀티플랫폼은 우리가 지원하는 모든 플랫폼에서 어플리케이션이 동일하게 동작하고 동일하게 보이도록지원해주는 아름답고 효율적인 프레임워크이다. 지금 당장 우리가 집중하고 있는것은 iOS를 위한 컴포즈 Beta 버전이다. 하지만 우리는 다른것들도 진행하고있다. 아래는 우리의계획이다. 

• 모든 Jetpack Compose 코어API와 멀티플랫폼 컴포넌트 제작
• iOS에서의 랜더링 퍼포먼스 향상
• iOS 앱용 컴포즈에서의 스크롤링, 문자 수정(text edting) 동작을 iOS네이티브 앱과 동일하게 만들기
• 모든 타입의 리소스를 공유할 수 있는 공통API 구현
• iOS와 데스크탑의 접근성 API 통합
• 멀티플렛폼 네비게이션을 위한 소루션 제공

앞서 말한 많은 개선사항은 컴포즈 for 데스크탑에도 역시 도움이 된다. 더욱이, 우리는 제품 사용자들의 피드백을 통해서 안정성 향상과 새로운 기능 향상 작업도 진행하고있다.

우리는 또한 컴포즈 for Web, 특히 Wasm에 대한 작업도 지속하고있다. 우리의 가장 가까운 목표는 컴포트 for Web을 알파 버전으로 만드는 것이다. 알파버전엔 다음이 포함된다. 

• 이미 존재하는 앱들의 포팅기능, 공통코드의 재사용 기능.
• 다양한 화면 사이즈(size, orientation, densitie) 지원,
• 마우스, 터치스크린, 키보드, 스크린 키보드 지원
• 퍼포먼스와 용량 향상.
•  

We’re committed to providing a great IDE experience for Kotlin Multiplatform. That means not only investing in the core platform and, for example, migrating Kotlin IDE plugin to K2 compiler frontend, but also providing a single tool (Fleet) for all Kotlin Multiplatform targets and codebases where you integrate it, eliminating the need to constantly switch between different IDEs.

We plan to quickly iterate over your feedback about using Fleet for Kotlin Multiplatform development  to make sure that we have everything you need for your development experience to be great. Among other things, we’re going to deliver in the following areas:

• Enhanced support for Compose Multiplatform, including live preview for common code and visual debugging tools.
• The IDE helping you with project configuration.
• Unified and enhanced debugging experience for all parts of your Multiplatform project.

우리는 Kotlin Multiplatform을 위한 훌륭한 IDE 환경을 제공하기 위해 최선을 다하고 있습니다. 이는 Kotlin IDE plugin을 K2 compiler frontend 마이그레이팅 하는것 같은 코어 플랫폼 뿐만 아니라 개발자들이 통합하게 될 모든 Kotlin Multiplatform 타겟과 코드베이스를 위한 싱글툴(Fleet)을 제공하여 끊임없는 IDE변경을 제거한다는 의미입니다. 

우리는 Fleet for Kotlin Multiplatform development의 사용성에 대한 피드백을 빠르고 반복적으로 처리하여 개발자들에게 훌륭한 개발 경험을 제공하려고 합니다. 이런 행위들 사이에서 우리는 아래와 같은것들을 제공할 것 입니다.

• 공통 코드를 위한 라이브 프리뷰와 시각적 디버깅 툴을 포함한 컴포즈 멀티플랫폼 서포트 증가
• IDE의 프로젝트 configuration 도움
• 멀티플랫폼 프로젝트의 모든 부분에서 통합되고 향상된 디버깅 경험 제공.

Kotlin Multiplatform의 가장 유명한 시나리오 중 하나는 iOS 타겟괴 코드를 쉐어 하는 것 이다. 코드 베이스에서 코틀린 멀티플랫폼 프레임워크를 사용하는 iOS개발자의 경험에 중점을 두고 있다. 

이 분야에서의 주요 계획은 Kotlin-to-Swift의 직접 번역(direct export)이다.  이를 통해 Object-C 보틀렉을 제거와 광범위한 Swift언어 지원, 자연스러운 API exporting이 가능해진다. 더욱이, 우리는 코틀린 라이브러리 개발자들을 위한 도구(tool)들을 만들었다. 이 도구들은 Swift로 export될 때  Kotlin API의 호환성과 사용자친화성을 개선하도록 디자인 되다. 우리는 툴링(tooling)에도 세심한 주의를 기울이고 있다. IDE와 빌드 시스템은 개발자 경험의 중요한 부분입니다. 우리의 목표는 Swift Export를 부드럽게 만드는 것 이다. 

우리의 또 다른 우선순위는 Kotlin/Native 컴파일의 속도 증가, CocoaPods의 강화, SwiftPM을 사용한프레임워크 exporting 서포트 소개 를 포함하고 있다. 

우리는 또한 코틀린 멀티 플랫폼 어플리케이션의 빌드 셋업 향상을 위한 방법도 지속적으로 탐험할 계획이다. Kotlin1.9.20애서 우리는 Gradle Multiplatform DSL의 거대한 향상을 릴리즈하여 읽고, 쓰기 쉽게 만들었다. 우리는 계속적으로 향상시킬 예정이다. 더욱이 우리는 Amper라는 실험을 하고있다. Amper는 사용성, 온보딩, IDE서포트에 초점을 맞춘 새로운 프로젝트 configuration tool이다. 

코틀린 멀티플랫폼의 에코시스템이 빠르게 성장함에 따라 라이브러리들의 이전 버전과의 호환성이 중요해졌다. 호환성을 위해서 JetBrains 팀과 라이브러리 제작자들은 함께 일해야만한다. 아래는 우리의 계획이다. 

• klib format 발전으로 라이브러리 크리에이터들이 그들의 JVM라이브러리 빌드 지식을 향상시킬 수 있다.
• 코틀린 멀티플랫폼의 code-inlining 행동이 JVM에서의 행동과 동일하도록 구현한다. 
• 멀티플랫폼 라이브러리의 퍼블릭 API들이 호환되지 않는 방향으로 변경되지 않게 하는 도구를 제공한다. 

우리는 또한 KMP라이브러리의 퍼플리싱 프로세스 향상할 것이다. 특히, 아래와 같은 계획이다. 

• Mac 없이 KMP라이브러리를 빌드하고 배포할 수 있게 만든다.
• KMP라이브러리를 생성하고, 배포하기 위한 템플릿과 광범위한 가이드라인을 제공한다. 

• Kotlin Multiplatform Is Stable and Production-Ready
• Compose Multiplatform 1.5.10 – The Perfect Time To Get Started
• Amper – Improving the Build Tooling User Experience
• Welcome Fleet with Kotlin Multiplatform Tooling
• Kotlin roadmap