우선 프레임워크가 무엇인지 알고가자!

Framework 란?

프레임워크는 말그대로 뼈대이다.

뼈대의 의미를 소프트웨어적인 관전에서 보면

아키텍쳐에 해당하는 골격 코드이다. 

(골격코드란? - 프로그램의 골자만 기술한 불완전한 형식의 명령어, 명령아가 사용될 때마다 완전하게 또는 상세히 지정해야만 한다.)

특정한 목적에 맞게 프로그래밍을 쉽게 하기 위한 약속.

모든 프레임워크는 어떤 언어를 기반으로, 어떠한 목적을 갖고 만들어졌다.

가장 헷갈려 하는 게 라이브러리 인데, 라이브러리는 우리가 직접 클래스를 new로 생성해서 사용하는 것이라고 보면 되고,

프레임워크는 내가 만든걸 framework가 사용해주는 것을 말한다.

이런 걸 제어의 역전(Inversion of Control), 뒤집혀진 라이브러리라고 한다.

개발자 입장에서 프레임워크를 본다면, 

다른 개발자 2명이 서로 다른 기술과 경험으로 코드를 작성한다고 해보자,

그리고 프로젝트가 끝나면 다른 사람이 프로젝트에 대해 유지보수를 할 수 있는데

2명 다 코드가 전혀 다르기 때문에 유지보수 하기가 힘들다.

근데 이때, 만약 뼈대(골격)가 같다면

각기 다른 자유분방한 코드보다는 유지보수가 수월할 것이다.

이러한 이유로 프레임워크가 탄생하게 되었다.

등장배경을 간략히 말하자면, EJB(엔터프라이즈 자바빈즈(Enterprise JavaBeans; EJB)는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. 즉, EJB는 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다. EJB 사양은 Java EE의 자바 API 중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고, EJB는 업무 로직을 처리하는 역할을 한다.)가 전에 개발자들이 사용하던 서버 애플리케이션이었는데 고가의 장비(WAS 등등)이 필요했고, 개발환경 설정 그리고 테스트 환경에 많은 애로사항이 있어서 훨씬 가볍게 애플리케이션을 개발할 수 있는 프레임워크인 Spring이 등장했다고 합니다. EJB에 비해 톰캣 컨테이너를 사용하고, 코드의 경량화 그리고 개발 중 테스트가 쉽다는 장점이 있습니다.

EJB에서 선언적 트랜잭션(자동적으로 예외처리, 커밋을 해주는 것이라고 생각하면 된다.), 분산 컴포넌트(Enterprise Component)라는 좋은 특징을 갖고 있었지만, 위에서 말한 것과 같이 어렵고 무겁고 테스트도 안되고 그랬는데, Spring에서 EJB의 좋은 특징을 갖고 단점을 줄여서 개발자들의 봄이 왔다고 해서 이름도 Spring이라고 지었다고 합니다. 

* 스프링프레임워크의 장단점 ?

프레임워크 장점

- 정형화 되어있어서 일정수준의 품질을 기대할 수 있고, 

유지보수가 쉽다. (프레임워크 숙달자 기준) 등

프레임워크 단점

- 습득시 노력과 시간이 필요하다. 

- 무겁다 등

스프링 장점 (다른 프레임워크에 비교)

- 개발자가 기본적인 디자인 패턴 (DI, AOP, 서비스 추상화 등)을 강제적으로 사용하도록 한다.

- 유연성이 좋다. 등

- 각 모듈을 조립(설정만 완벽하게 하면)하면 기능을 쉽게 구현가능하다.

- 모듈(기능) 추가및 제거 - 관리가 수월하다. 

스프링 단점

- 습득시간이 오래 걸린다.

- 무겁다. model 1 방식 개발방식에 비해서 상대적으로?

- 스프링 설정하는 것에만 익숙해지다보니 코딩 실력이 떨어지게됨. 

(스프링이 구현해 놓은걸 직접 구현하면서 코딩실력을 늘릴수 있는데 그렇게 못해서..)

출처 

alsyean.tistory.com/23

coneseo.tistory.com/31
https://keehyun2.tistory.com/entry/스프링-프레임워크-장단점-분석 [khp blog]

JSP란 무엇일까?

Java Server Pages의 약자이며,

HTML 코드에 자바 코드를 넣어 동적웹페이지를 생성하는 웹어플리케이션 도구이다.

JSP가 실행되면 자바 서블릿(Servlet)으로 변화되며 웹 어플리케이션 서버에서 동작되면서 필요한 기능을 수행하고

그렇게 생성된 데이터를 웹페이지와 함께 클라이언트로 응답한다.

위와 같이 정의만 보고는 이해하기가 쉽지 않기 때문에 몇가지 개념을 알고 가자!

• 웹
• 웹 어플리케이션
• 자바 서블릿
• JSP 와 서블릿

웹(Web)

웹이란 인터넷 기반의 정보기술로 World Wid Web의 줄입말로 쓰이며 WWW 라고도 한다.

전세계에 거대한 네트워크 망을 통해 정보를 공부하며 정보의 흐름은 양방향성을 가진다.

웹 어플리케이션(Web Application)

웹 어플리케이션은 웹에서 실행되는 응용프로그램을 뜻하며 인터넷을 통한 은행업무, 인터넷쇼핑 등등 인터넷에서 하는 여러 서비스를 총칭하며 사용자가 필요한 요청(Request)를 하고 서버에서는 이에 해당하는 요청을 수행하고 그리고 요천한 데이터를 응답(Response)한다.

웹 어플리케이션이 위와 같이 동작하기 위한 몇가지 구성요소가 있다.

웹 브라우저(Web Browser) : 클라이언트에서 요청을 하고 전달받은 페이지를 볼수있는 환경을 말한다.  ( 크롬, IE, Safari, Firefox 등.. )

웹 서버(Web Server)  : 클라이언트로 부터 요청받아 서버에 저장된 리소스를 클라이언트 에게 전달한다. 주로 정적컨텐츠롤 담당한다.

웹 어플리케이션 서버 ( Web Application Server ) : 줄여서 was 라고도 부르며 서버단에서 필요한 기능을 수행하고 그결과를 웹서버에게 전달한다.

데이터베이스 : 서비스에 필요한 데이터를 보관, 갱신 등 관리를 한다.

자바 서블릿(Java Servlet)

서블릿이란 웹페이지를 동적으로 생성하기 위해 서버측 프로그램을 말한다.

이는 자바 언어를 기반으로 만들어지며 웹 어플리케이션 서버(Web Application Server) 위에서 컴파일 되고 동작한다.

JSP 와 서블릿

JSP 와 서블릿의 차이점은 결과적으로 하는 일은 동일하지만

JSP 는 HTML 내부에 JAVA 소스코드가 들어감으로 인해 HTML 코드를 작성하기 간편하다는 장점이 있으며

서블릿은 자바 코드내에 HTML 코드가 있어서 읽고 쓰기가 굉장히 불편하기 때문에 작업의 효율성이 떨어진다. 

하지만 웹을 공부할때 JSP 와 서블릿은 함께 배운다,

그건 왜 때문일까..?

JSP 로 작선된 프로그램은 서버로 요청시 서블릿(Servlet) 파일로 변환되어 JSP 태그를 분해하고 추출하여 다시 순수한 HTML를 변환한다.

(출처: https://javacpro.tistory.com/43 [버물리의 IT공부])

 아래 이미지 참고!(출처:velog.io/@dlsdk2526/JSP와-서블릿)

JSP 의 장단점 

풀네임 : Java Server Page

구현언어 : Java

오픈소스 : X

벤더 : 오라클 Oracle

프레임워크 : Spring

WAS : Tomcat

장점 : 객체지향 설계로 큰 프로젝트에서 강점을 보인다. 주축이 되는 강력한 프레임워크가 존재한다. 벤더가 거대 기업이고, 한국에서 굉장히 많이 쓰이고 있다.

단점 : 각종 모듈을 설치해야 해서 가벼운 프로젝트에 어울리지 않고, 프레임워크를 잘 사용하지 않으면 개발이 힘들 수 있다. 또한 2019년 부터 기업사용자는 비용이 발생한다는 공식적인 발표가 있다.

오늘은 프레임워크와 라이브러리의 차이점에 대해 알아보자!

일단 프레임워크와 라이브러리는 둘다 다른 누군가가 쓴 코드인데, 우리의 프로젝트를 위해서 가져다가 쓰는거야!

즉, 우리의 코딩 삶을 윤택하게 하기 위해서 가져다가 쓰는 것들

라이브러리, 프레임워크를 가르는 차이점은 아주 간단한 컨셉이야!

Who is controlling ??? 누가 누구를 컨트롤 하는가! 이다.

너가 코드를 컨트롤하는건지 vs 누군가의 규칙을 따라 코딩하는건지

예를 들어, 라이브러리의 가장 좋은 예시는 JQuery 야! 제이쿼리는 웹사이트에 인터렉티브한 요소를 넣을 수 있는데 그래서 내가 웹사이트를 코딩을 하고 있는데 내가 필요할때, "내가" 제이쿼리를 소환을 해.

코딩을 하다가 필요할때 제이쿼릐를 부르는 거고, "내가"(나자신) 코딩을 해나가는 거지. 이게 라이브러리야! (우리가 필요할때 라이브러리를 쓰는거야. 그리고 라이브러리는 정말 쉽게 대체될 수 있어 = 내가 원하면 제이쿼리를 다른걸로 대체해도 돼! 그런다고 프로젝트가 망가지지도 않아, 왜냐면 시간절약하려고 소환하는 그런거니깐)

자. 하지만! 프레임워크는 달라! 왜냐 너가 프레임워크를 부르는 것이 아니거등! "프레임워크"가 너를 부르는 거지!

바로 이게 가장 명확한 라이브러리와 프레임워크의 차이점이야!

프레임워크로 일을 할때는 프레임워크의 규칙을 따라야해! 너가 코드의 규칙을 결정하는 입장이 아니거든! 

프레임워크가 어떻게 하라고 알려주는 거야! 프레임워크가 어디에 코드를 넣어야하는지 등등을 알려줘!

즉, 프레임워크가 너에게 규칙을 알려주는 거야! 어디에 템플릿을 넣고, 컨트롤러를 넣고, 뷰를 넣고..... 규칙에 따라서 하면 모든건 정상작동하겠지. 너가 컨트롤 하는건 없어. 그냥 규칙을 따라갈뿐.

프레임워크의 좋은 예시는 장고 웹 프레임워크임(django). 장고 웹 프레임워크는 규칙이  정말 많아. 잘 작동하기를 바란다면, 모든 규칙을 잘 준수해야하지.

예를 들어, 장고에서 어디민 패널을 만들고 싶다면, 무조건 코드를 admin.py에 써야해.

만약 URL을 바꾸고 싶다면? 반드시 파일명 url.py를 가야하듯이!

왜냐면 장고가 시작할때 url.py. admin.py를 읽거든.

너가 이걸 바꿀수는 없어. 이건 장고가 갖고있는 규칙이야. 이걸 잘 준수해야 어드민 패널, URL이 잘 작동하는걸 볼 수 있엉.

다시말해, 이 시나리오에서는 내가 장고를 부르고 그런거 없음. 장고 문서를 보면서 장고 규칙에 따라 코드들을 잘 넣어두면, 장고가 그걸 실행시키는 거니깐.

프레임워크라고 하는 것들은 반드시 따라야 하는 규칙이 있어.

라이브러리는 우리가 필요할때 부르는 것들인거고!

-> "내가" 라이브러리를 부르는 것이고 / "프레임워크"가 나를 부르는 거야!

그러니깐 "000을 빌드하기 위한 000 라이브러리"이면 너가 필요할때마다 부를 수 있는 것이라는 걸 알거야! (ex. A JavaScript library for builing user interfaces)

반대로 "000을 빌드하기 위한 프레임워크"이면 이건 규칙과 문서가 따라오는 것이며. 너가 적극 수용해야해. (ex. The Web framework for perferctionists with deadlines)

그런데 말이지! 리액트JS 웹사이트에 가면... "리액트는 라이브러리라고" 말을 해. 즉. 너의 어플리케이션의 UI를 빌드할때 리액트를 부르는거야. 이 경우 "너가" 리액트를 부르는 거지. 너가 부르는 것이니까. 리액트는 라이브러리가 되는 것이 맞지. 그리고 리액트는 그런 규칙,, 폴더 구조나 컴포넌트명이나, 그런게 없어. 하지만, "리액트가" 우리의 컴포넌트를 부르긴 하지. 그래서 이 경우엔 리액트를 프레임워크로 부를 수 있는 거야. 왜냐하면 리액트가 컴포넌트를 부르는거니깐. 규칙을 알려주고 말이지. 뭐가 틀리고, 뭐가 맞는지를 알려주거든. 너가 컴포넌트를 쓰면, 리액트가 그걸 불러와서 스크린에 보여줘! 그래서 꽤나 회색의 영역이고 관려하여 많은 구글 검색이 가능할거야!

어떤 사람들은 리액트는 라이브러리다. 너가 필요할때 부르니깐. 동시에 프레임워크로 불릴 수 있다. 컴포넌트를 불러오니깐~

리액트가 우리의 컴포넌트를 인터렉티브하게 만들어주니까! 리액트가 states. props 같은 걸 컴포넌트에게 주니까.

이건 Vue.js도 마찬가지야!

그런데 이게 라이브러리인지 프레임워크인지 규정하는게 중요한가?

나는 상관없다고 보는게. 프론트엔드에서 뭐든 다 이모양이거든(모르겠다.. 몰랐겠지.. 몰랐더라도... 몰랄겠구나... 모를수록... 몰랐으니)ㅋㅋㅋㅋㅋㅋ 하지만 적어도. 우리는 개념상으로는 이해하고 있어야 된다고 생각해! 이 둘의 차이가 무엇인지 말야.

즉. 둘의 경계가 항상 뚜렷하지는 않지만, 최소한의 프레임워크와 라이브러리의 개념 차이는 알고있자!

https://youtu.be/t9ccIykXTCM

DI(의존성 주입)를 해야하는 이유는 ?

DI로 프로그램을 설계 했을 때, 다음과 같은 이점을 얻을 수 있습니다.

• Unit Test가 용이해진다.
• 코드의 재활용성을 높여준다.
• 객체 간의 의존성(종속성)을 줄이거나 없엘 수 있다.
• 객체 간의 결합도이 낮추면서 유연한 코드를 작성할 수 있다.

즉, 한 클래스를 수정하였을 때, 다른 클래스도 수정해야 하는 상황을 막아줄 수 있습니다.

※ DI, 의존성 주입은 필요한 객체를 직접 생성하는 것이 아닌 외부로 부터 필요한 객체를 받아서 사용하는 것이다. 이를 통해 객체간의 결합도를 줄이고 코드의 재활용성을 높여준다.

오늘은 관심사 분리에 대해 공부해보자!

* 관심사 분리란 ??

- 소프트웨어 상에서 구조를 패턴, 역할, 기능 등 각각 맞게 섹션 별로 분리해서 작성하는 것을 말합니다. 이때 주의 사항은 분리를 해서 작성을 했을시, 그 특성에 맞게 하나의 역할을 부여해서 작성해야 하는 것입니다. 즉, 코드를 작성할때 '관심사의 분리'란 하나의 역할 별로 분리를 해서 작성하는 것을 말합니다.

쉽게 말해! 치료는 의사에게, 주사는 간호사에게, 약은 약사에게 처럼 목적에 맞게 또는 상황에 맞게 역할을 분리해주는 것입니다. 

PCB(Process Control Block, 프로세스 관리 블록) ?

• 커널에 등록된 각 프로세스에 대한 정보를 저장하는 영역
• 커널 공간(kernel space)내에 존재
• OS는 PCB의 정보를 사용하여 프로세스를 관리

PCB에 저장되는 정보

• 프로세스 고유번호(PID : Process Identification)
• 프로세스 우선순위(Priority)
  

• 프로세스 현재 상태(Current state)

• 문맥 저장 영역(Context save area)

# 프로세스(Process)의 개념

#프로세스의 상태(Process State)

○ 생성(New) 상태

→ 프로세스가 생성되었지만 아직 운영체제에 의해 실행가능하게 되지 못 한 상태

○ 준비(Ready) 상태

→ 프로세스가 실행을 위해 CPU(Processor)를 할당받기를 기다리는 상태

○ 실행(Run) 상태

→ 프로세스가 CPU(Processor)를 할당받아 실제로 실행되는 상태

▒ 디스패치(Dispatch) ?

- Ready 상태의 프로세스가 CPU를 할당받아 Run 상태로 전이되는 과정

▒ Time Runout?

- Run 상태의 프로세스에 할당된 CPU 사용시간이 완료되어 Ready 상태로 되돌아가는 과정

○ 종료(Exit)상태

→ 프로세스가 실행이 완전히 끝나고 CPU 할당이 해제된 상태

○ 대기(Wait)상태

→ 프로세스가 CPU(Processor)를 할당받아 실행되다가 어떤 사건이 발생(ex. 입 · 출력 작업이 완료)할 때까지 멈추어 있는 상태

▒ Wake Up?

- 대기(Wait) 상태에 있던 프로세스가 기다리던 어떤 사건의 발생(입 · 출력 작업이 완료)으로 인해 나머지부분의 실행을 위해 준비(Ready) 상태로 전이되는 과정

새로운 저장소 만들기

폴더를 하나 만들고, 그 안에서 아래 명령을 실행하세요.

git init 

새로운 git 저장소가 만들어집니다. 

저장소 받아오기

로컬 저장소를 복재(clone)하려면 아래 명력을 실행하세요.

git clone / 로컬/ 저장소 / 경로

원격 서버의 저장소를 복제하려면 아래 명령을 실행하세요.

git clone 사용자명@호스트 : / 원격 / 저장소 / 경로

작업의 흐름

여러분의 로컬 저장소는 git이 관리하는 세 그루의 나무로 구성되어 있어요.

1. 작업 디렉토리(Working directory) - 실제 파일들로 이루어져있음

2. 인덱스(Index)는 준비 영역(staging area)의 역할을 함

3. HEAD는 최종 확정본(commit)을 나타냄

추가와 확정(commit)

변경된 파일은 아래 명령어로 (인덱스에) 추가할 수 있어요.

git add <파일 이름>

git add *

이것이 바로 git의 기본 작업 흐름에서 첫 단계에 해당됩니당.

하지만 실제로 변경 내용을 확정하려면 아래 명령을 내려야 합니다.

git commit -m "이번 확정본에 대한 설명"

자, 이제 변경된 파일이 HEAD에 반영되었어요.

하지만, 원격 저장소에는 아직 반영이 안되었어요.

변경 내용 발행(push)하기

현재의 변경 내용은 아직 로컬 저장소의 HEAD안에 머물고 있어요.

이제 이 변경 내용을 원격 서버로 올려봅시다. 아래 명령을 실행하세요.

git push origin master

(다른 가지를 발행하려면 master를 원하는 가지 이름으로 바꿔주세요.)

만약 기존에 있던 원격 저장소를 복제한 것이 아니라면, 

원격 서버의 주소를 git에게 알려줘야 합니당.

git remote add origin <원격 서버 주소>

이제 변경 내용을 원격 서버로 발행할 수 있어용!

가지(branch)치기

가지는 안전하게 격리된 상태에서 무언가를 만들 때 사용합니당.

여러분이 저장소를 새로 만들면 기본으로 master가지가 만들어져요.

이제 다른 가지를 이용해서 개발을 진행하고, 나중에 개발이 완료되면

master가지로 돌아와 병합하면 됩니당.

아래 명령으로 "feature_x"라는 이름의 가지를 만들고 갈아탑니다.

git checkout -b feature_x

아래 명령으로 master가지로 돌아올 수 있어요.

git checkout master

아래 명령을 치면 가지를 삭제할 수 있어요.

git branch -d feature_x

여러분이 새로 만든 가지를 원격 저장소로 전송하기 전까지는 

다른 사람들이 접근할수 없어요. 

git push origin <가지 이름>

갱신과 병합(merge)

여러분의 로컬 저장소를 원격 저장소에 맞춰 갱신하려면 아래 명령을 실행하세요.

git pull

이렇게 하면 원격 저장소의 변경 내용이 로컬 작업 디렉토리에 

받아지고(fetch), 병합(merge)된 답니다.

다른 가지에 있는 변경 내용을 현재 가지(예를 들면, master가지)에 

병합하려면 아래 명력령을 실행하세용.

git merge <가지 이름>

첫번째 명령이든, 두번째 명령이든 git은 자동으로 변경 내용을 병합하려고해요.

문제는 항상 성공하는게 아니라 가끔 충돌(conflicts)이 일어나기도 한다는거~ㅜ

이렇게 충돌이 발생하면, git일 알려주는 파일의 충돌 부분을

직접 수정해서 병합이 가능하도록 해야 합니다.

충돌을 해결했다면 아래 명령으로 git에게 아까의 파일을 병합하라고 알려줘요!

git add <파일 이름>

변경 내용을 병합하기 전에 , 어떻게 바뀌었는지 비교도 가능해용.

git diff <원래 가지> <비교 대상 가지>

꼬리표(tag) 달기

소프트웨어의 새 버전을 발표할 때마다 꼬리표를 달아놓으면 좋아요.

(물론 꼬리표는 SVN 등에 이미 존재하는 기능이지만,)

아래 명령을 실행하면 새로운 꼬리표인 1.0.0을 달수 있어요.

git tag 1.0.0 1b2e1d63ff

위 명령에서 1b2e1d63ff부분은 꼬리표가 가리킬 확정본 식별자입니다.

아래 명령으로 확정본 식별자를 얻을 수 있어요.

git log

확정본 식별자의 앞부분 일부만 입력해도 꼬리표를 불일 수 있지만, 

그 일부분이 반드시 고유하다는 조건이 필요해요.

로컬 변경 내용 되돌리기

만약 여러분이 (물론 그럴 일은 없겠지만) 실수로 무언가 잘못한 경우,

아래 명령으로 로컬의 변경 내용을 되돌릴 수 있어요.

git checkout -- <파일 이름>

위 명령은 로컬의 변경 내용을 변경 전 상태(HEAD)로 되돌려줍니당

다만, 이미 인덱스에 추가된 변경 내용과

새로 생성한 파일은 그래도 남는답니다.

만약, 로컬에 있는 모든 변경 내용과 확정본을 포기하려면, 

아래 명령으로 원격 저장소의 최신 이력을 가져오고, 

로컬 master 가지가 저 이력을 가리키도록 할 수 있어요.

git fetch origin

git reset --hard origin/master

유용한 힌트

git의 내장 GUI

gitk

콘솔에서 git output을 컬러로 출력하기

git config color.ui true

이력(log)에서 확정본 1개를 딱 한 줄로만 표시하기

git config format.pretty oneline

파일을 추가할 때 대화식으로 추가하기

git add -i

자바 메모리 구조

※ 메모리 구조를 알아야 하는 이유는? 

• 같은 기능의 프로그램을 사용하더라도 메모리 관리에 따라 성능이 좌우됨

• 메모리가 제대로 관리되지 않을 경우 속도저하 현상이나 튕김 등의 서비스의 영향이 생김

• 한정된 자원(메모리)을 효율적으로 사용하여 최고의 성능을 내기 위함

자바 프로그램의 실행구조

메모리 구조를 알아보기 전, 자바 프로그램이 실행되는 순서를 먼저 이해하는 것이 좋다.

프로그램이 실행되기 위해서는 윈도우나 리눅스같은 운영체제(OS)가 제어하고 있는 시스템의 리소스의 일부인 메모리(RAM : 주기억장치)를 제어할 수 있어야 한다. java이전의 C같은 언어로 만들어진 프로그램은 이러한 이유 때문에 운영체제(OS)에 종속되어 실행되게 되어 있었다.

반면, java프로그램은 JAM(Java Virtual Machine) 이라는 프로그램만 있으면 실행이 가능하다. JVM이 OS에게서 메모리 사용권한을 할당받고 JAM이 자바 프로그램을 호출하여 실행하게 된다. OS에서는 독립되었지만 JVM이라는 프로그램에 종속적이게 된다.(JVM을 실행시키고 다시 JVM이 프로그램을 실행시키는 방식이다 보니 OS에서 직접 제어 받는 방식보다는 속도면에서 느리다.)

※ JVM이란?

• Java Virtual Machine
• JAVA와 OS 사이에서 중계자 역할
• JAVA가 OS에 구애받지 않고 재사용을 가능하게 해 줌
• 메모리 관리 기능(Garbage Collection)

자바프로그램 실행 과정과 JVM메모리 구조

프로그램이 실행되면, JVM은 OS로부터 이 프로그램이 필요로 하는 메모리를 할당받고, JVM은 이 메모리를 용도에 따라 여러 영역으로 나누어 관리한다.

• JAVA Source : 사용자가 작성한 JAVA 코드
• JAVA Compiler　: JAVA 코드를 Byte Code로 변환시켜주는 기능
• Class Loader :　Class파일을 메모리(Runtime Data Area)에 적재하는 기능
• Execution Engine : Byte Code를 실행 가능하게 해석해주는 기능
• Runtime Data Area : 프로그램을 수행하기 위해 OS에서 할당 받은 메모리 공간

• Last In First Out (LIFO) 방식
• 메서드 호출 시마다 각각의 스택프레임(그 메서드만을 위한 공간)이 생성되게 됨.
• 메서드 안에서 사용되어지는 값들 저장, 호출된 메서드의 매개변수, 지역변수, 리턴 값 및 연산 시 일어나는 값들을 임시로 저장

• 메서드 수행이 끝나면 프레임별로 삭제

3. 힙 영역

•  new 연산자로 생성된 객체와 배열을 저장하는 공간

•  클래스 영역에 로드된 클래스만 생성가능

• Garbage Collector를 통해 메모리 반환

1. Permanent Generation

   - 생성된 객체들의 정보의 주소 값이 저장된 공간

2. New Area
   - Eden : 객체들이 최초로 생성되는 공간
   - Survivor : Eden에서 참조되는 객체들이 저장되는 공간

3. Old Area : New Area에서 일정시간이상 참조되고 있는 객체들이 저장되는 공간

4. Native 매소드 영역 (Native method stack area)

• 자바 외의 다른 언어에서 제공되는 메소드들이 저장되는 공간

5. PC 레지스터 (PC Register)

• Thread가 생성 될 때마다 생성되는 공간

• Thread가 어떤 부분을 어떤 명령으로 실행할 지에 대한 기록

• 현재 실행되는 부분의 명령과 주소를 저장
  
  

Garbage Collection

• 참조되지 않은 객체들을 탐색 후 삭제

• 삭제된 객체의 메모리를 반환

• Heap 메모리의 재사용

1.  Minor Garbage Collection

   i) New 영역에서 일어나는 Garbage Collection
   ii) Eden영역에 객체가 가득 차게 되면 첫 번째 Garbage Collection 발생
   iii) Survivor1 영역에 값 복사
   iv) Survivor1 영역을 제외한 나머지 영역의 객체들을 삭제
   v) Eden영역과 Survivor1영역의 메모리가 기준치 이상일 경우, Eden 영역에 생성된
   객체와 Survivor1영역에 있는 객체 중 참조되고 있는 객체가 있는지 검사
   vi) 참조되고 있는 객체를 Survivor2 영역에 복사
   vii) Surviver2 영역을 제외한 영역의 객체들을 삭제
   viii) 일정시간이상 참조되고 있는 객체들을 Old영역으로 이동
   ix) 반복

2. Major Garbage Collection (Full Garbage Collection)
   

   i) Old영역에 있는 모든 객체들을 검사
   ii) 참조되지 않은 객체들을 한꺼번에 삭제
   iii) Minor Garbage Collection에 비해 시간이 오래 걸리고 실행 중 프로세스가 정지