<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Jvm on Gukin Han</title>
    <link>https://gukin.dev/tags/jvm/</link>
    <description>Recent content in Jvm on Gukin Han</description>
    <generator>Hugo</generator>
    <language>ko-kr</language>
    <lastBuildDate>Wed, 04 Feb 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://gukin.dev/tags/jvm/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>자바 객체 생성(new) 비용은 비쌀까? - 힙 메모리 할당 과정 3단계 분석</title>
      <link>https://gukin.dev/posts/jvm-object-creation-heap-allocation/</link>
      <pubDate>Wed, 04 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://gukin.dev/posts/jvm-object-creation-heap-allocation/</guid>
      <description>&lt;h2 id=&#34;들어가며&#34;&gt;들어가며&lt;/h2&gt;
&lt;p&gt;이전 포스팅들은 &lt;strong&gt;스택 영역에서의 바이트코드의 상호작용&lt;/strong&gt;을 다뤘다. 런타임 데이터 영역에는 스택 영역 뿐만 아니라 &lt;strong&gt;힙 영역&lt;/strong&gt;이 존재한다. &lt;a href=&#34;https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.5.3&#34;&gt;JVM 스펙&lt;/a&gt;에 따르면 다음 내용을 확인할 수 있다:&lt;/p&gt;
&lt;p&gt;&lt;img alt=&#34;2.5.3. Heap&#34; loading=&#34;lazy&#34; src=&#34;https://gukin.dev/posts/jvm-object-creation-heap-allocation/img.png&#34;&gt;&lt;/p&gt;
&lt;p&gt;&amp;ldquo;자바 가상 머신은 모든 스레드가 공유하는 힙(Heap) 영역을 가지고 있습니다. 힙은 &lt;strong&gt;모든 클래스 인스턴스와 배열의 메모리가 할당되는&lt;/strong&gt; 런타임 데이터 영역입니다.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;따라서, 이 글에서는 &lt;strong&gt;객체와 힙 영역&lt;/strong&gt;에 관련된 여러 요소들을 탐험하고 실험하는데 목적이 있다.&lt;/p&gt;
&lt;h2 id=&#34;object-클래스의-객체-생성-new-키워드&#34;&gt;Object 클래스의 객체 생성 (new 키워드)&lt;/h2&gt;
&lt;p&gt;처음으로 시도해볼 실험은 &lt;strong&gt;가장 순수한 객체를 생성&lt;/strong&gt;해보는 것이다. 아무런 필드도, 로직도 없는 가장 순수한 형태의 객체를 생성해 볼 수 있는 클래스는 &lt;strong&gt;java.lang.Object&lt;/strong&gt;이다. Object 객체를 생성할때 과연 &lt;strong&gt;몇 번의 CPU 명령어를 소모할까? 어떤 과정을 거칠까?&lt;/strong&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>바이트코드로 이해하는 자바 제어 흐름(Control Flow)</title>
      <link>https://gukin.dev/posts/jvm-control-flow-bytecode/</link>
      <pubDate>Sun, 25 Jan 2026 00:00:00 +0000</pubDate>
      <guid>https://gukin.dev/posts/jvm-control-flow-bytecode/</guid>
      <description>&lt;h2 id=&#34;들어가며&#34;&gt;들어가며&lt;/h2&gt;
&lt;p&gt;&lt;a href=&#34;https://gukin.dev/posts/jvm-stack-machine-bytecode-analysis/&#34;&gt;이전 포스팅&lt;/a&gt;에서는 컴파일된 증감연산자(i++, ++i)의 &lt;strong&gt;정적인 바이트코드&lt;/strong&gt;를 분석했다. 해당 실험에서는 load, store 등의 명령어를 피연산자 스택을 통해 어떻게 연산이 이뤄지는지, iinc 명령어의 최적화 방식을 이해할 수 있었다.&lt;/p&gt;
&lt;p&gt;이번에는 단순한 연산을 벗어나, 프로그램의 실행 순서를 바꾸고 제어하는 **제어 흐름(Control Flow)**을 다뤄보려고 한다. 코드의 흐름을 나누는 분기문(if-else), 특정 구간을 반복하는 반복문(for-loop, while), 조건에 따라 특정 점프하는 스위치문(switch)에 해당된다.&lt;/p&gt;
&lt;p&gt;각각 바이트코드 레벨에서 어떻게 흐름을 제어하는지 실험을 통해 살펴본다.&lt;/p&gt;
&lt;h2 id=&#34;실험&#34;&gt;실험&lt;/h2&gt;
&lt;p&gt;java 코드를 작성하고 javac ControlFlowTest.java 와 javap -c -p -v ControlFlowTest &amp;gt; result.txt 명령어를 이용해서 컴파일과 역어셈블을 하였다. 3개의 섹션을 나눠서 각각 분기문, 반복문, 스위치문을 실험 및 분석하였다.&lt;/p&gt;</description>
    </item>
    <item>
      <title>레지스터 vs 스택 머신 - 자바는 왜 스택 방식을 택했는가? (바이트코드 분석)</title>
      <link>https://gukin.dev/posts/jvm-stack-machine-bytecode-analysis/</link>
      <pubDate>Mon, 19 Jan 2026 00:00:00 +0000</pubDate>
      <guid>https://gukin.dev/posts/jvm-stack-machine-bytecode-analysis/</guid>
      <description>&lt;h2 id=&#34;들어가며&#34;&gt;들어가며&lt;/h2&gt;
&lt;p&gt;이 글은 거창하게 바이트코드를 분석하려는 의도로 시작하지 않았다. 단지 JVM을 학습하는 과정에서 제시된 간단한 실습 예제를 직접 실험해보고 있었다. 작성된 자바 파일을 javac와 javap 명령어로 &lt;strong&gt;컴파일하고 역어셈블(Disassemble)하는 과정&lt;/strong&gt;은 생각보다 많은 질문을 던져주었다.&lt;/p&gt;
&lt;p&gt;&amp;ldquo;우리가 작성한 소스코드는 실제로 &lt;strong&gt;JVM 위에서 어떻게&lt;/strong&gt; 돌아갈까?&amp;rdquo;
&amp;ldquo;단순한 i++ 연산은 &lt;strong&gt;CPU와 메모리 관점&lt;/strong&gt;에서 어떤 비용을 지불하는가?&amp;rdquo;&lt;/p&gt;
&lt;p&gt;이러한 질문을 가지고 실험을 하면서, 컴파일러의 최적화와 JVM의 &lt;strong&gt;스택 머신 아키텍처 특징&lt;/strong&gt;을 바이트코드와 그 연산 플로우에서 확인할 수 있었다. 이 글에서는 간단한 증감 연산자(i++) 실험을 통해 소스코드가 바이트코드로 변환될 때 발생하는 차이와 그 원리를 정리해본다.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Java 스레드의 메모리 관리와 할당에 대한 이해</title>
      <link>https://gukin.dev/posts/java-thread-memory-allocation/</link>
      <pubDate>Sun, 04 May 2025 00:00:00 +0000</pubDate>
      <guid>https://gukin.dev/posts/java-thread-memory-allocation/</guid>
      <description>&lt;h2 id=&#34;배경&#34;&gt;배경&lt;/h2&gt;
&lt;p&gt;Spring Boot에서는 Async 어노테이션으로 비동기 메서드를 쉽게 작성할 수 있다. 우리 팀에서 운영 중인 서비스에는 알림 생성 로직을 비동기로 실행하고 있다. 그 알림들 자체는 미래에 발생하기 때문에 동기적으로 작성할 필요가 없고, 유저들에게 응답속도를 높이기 위한 결정으로 보였다.&lt;/p&gt;
&lt;p&gt;Spring Boot의 코어 기능인 AutoConfiguration 덕분에 ThreadPoolTaskExecutor 빈도 자동으로 등록되지만, 실무에서는 IO-Bound, CPU-Bound 등 목적에 맞는 스레드 풀을 만들어 운영할 필요가 있다. 서로 다른 특성을 가진 작업을 혼합해서 사용하면 비효율이 발생하기 때문이다. CPU 사용이 낮은 IO-Bound 작업은 코어보다 많은 수의 스레드를 풀에 담아 사용하고, CPU 사용률이 높아 컨텍스트 스위칭 비용이 높은 CPU-Bound 작업은 코어 수에 비례해서 제한해야 한다.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
