728x90
반응형
SMALL

* Youtube Link - https://www.youtube.com/watch?v=24f2-eJAeII

 

메모리 누수 (Memory Leak)

메모리를 꽉 채우면 컴퓨터가 뻗는다.

 

Manage language

가비지 컬렉터를 사용하는 프로그래밍 언어

 

Mark and sweep

필요한 것만 마크하고, 마트되지 않은 것들은 버리는 것

프로그래밍 적으로는 루트에서 닿지 않는 변수들을 치우는 것

 

Reference counting (참조 카운팅)

한 요소가 다른 요소에게 몇 번 참조가 되는지 세어서 그 수가 0이 되면 치우는 것이다.

 

최근에는 자바가 슬슬 멀티쓰레드로 돌면서 주어간다.

하지만 자바의 가비지 컬렉터에도 한계가 있다.

100% 주어가지는 못한다.

 

좋은 프로그래머가 되려면 메모리 관리에도 신경을 써야 한다.

각 프로그래밍 언어마다 메모리 누수를 위한 방법이 다르다.

어떤 언어에서는 성능 개선이 일어나는데, 어떤 언어에서는 성능 악화가 일어난다.

그래서 각 프로그래밍 언어에 대한 메모리 관리 방법을 알아두는 것도 좋다.

 

순환 참조

Reference가 0이 안된다.

 

감사합니다.

728x90
반응형
LIST
728x90
반응형
SMALL

*Youtube Link - https://www.youtube.com/watch?v=ToO_gpWiMQc

 

 

 

 

 

감사합니다.

728x90
반응형
LIST
728x90
반응형
SMALL

*Youtube Link - https://www.youtube.com/watch?v=vXLChm1OM8c&list=PLCkO8I_DSQ7daVh7QwAnyW3_3mpLvWiAD

 

제목: JAVA Applicatoin 성능 관리의 기초

목차:

I: 주요 성능 이슈 발생 유형

1) 잘못된 용량 산정

실제로 오픈했을 때 예상보다 많은 사용자가 들어온다든지 아니면

처음에 설정을 잘못함으로 인해서 하드웨어 처리량을 초과해서 발생하는 성능 이슈들이 종종 있다.

용량 산정을 잘못했다보니 아키텍처 자체를 구성을 잘못해서 발생할 수 있는 

그런 성능 이슈들도 있다.

2) Heap 메모리 부족

힙 메모리 부족은 요즘도 종종 발생할 수 있는 사례들이다.

크게 두 가지 이슈가 있는데

첫번째는 OutOfMemory와 관련된 이슈이다.

힙 메모리 크기를 절대적으로 작게 잡았을 때나 

어플리케이션 메모리 누수가 있었을 때 이렇게 크게 

두 가지로 나누어볼 수 있다.

아웃 오브 메모리의 경우 서비스 자체가 안 된다.

두번째는 가비지 컬렉션과 관련해서 발생하는 이슈이다.

서비스 지연이 발생하는 케이스이다.

3) DataBase 성능 이슈

 

 

감사합니다.

728x90
반응형
LIST
728x90
반응형
SMALL

* Youtube Link - https://www.youtube.com/watch?v=AWXPnMDZ9I0

 

1. 소스 코드 작성

Person이라는 객체를 만들었다. 이름은 "이정록" 그리고 나이는 26이다.

Person이라는 객체 타입의 p 변수를 만들었다.

이 p 변수는 Person 객체의 모든 method들을 사용할 수 있다.

이클립스에서 run 버튼을 누르면 이 소스 코드들이 컴파일 되고 실행된다.

 

변수들은 어디에 저장이 되고

어떻게 구동이 되는 걸까요?

 

2. 소스코드의 바이트 코브 변환

방금 본 자바 소스 코드는 .java의 형태로 저장이 된다.

그리고 이 자바 소스 파일을 자바 컴파일러가 바이트 코드로 바꿔주는데 이것은 .class파일로 저장이 됩니다.

작성한 코드를 숨기는 1차원의 의미도 있지만

바이트 코드로 바꿨으니까 문법 검사와 같은 작업을 이후에는 하지 않게 되면서 시간을 단축시키는 의미도 있다고 합니다.

그러나 이 방식은 소스 코드 변경시마다 컴파일을 하고 실행시켜야 되기 때문에 시간이 조금 오래 걸린다.

3. 클래스 파일 (바이트 코드)

이렇게 변경된 바이트 코드 즉, 클래스 파일들은 클래스 로더가 JVM 메모리 영역 즉 Runtime Data Area로 로딩시킵니다.

Runtime Data Area는 총 5개의 영역으로 구분되어 있습니다.

메서드와 힙영역은 모든 스레드가 공유하는 영역이고

스택, PC 레지스터, 네이티브 메서드 스택은 스레드 마다 하나씩 생성되는 공간입니다.

3.1 메서드 영역

메서드 영역은 JVM이 시작될 때 생성되는 공간으로 바이트코드가 이 영역에 저장됩니다.

모드 스레드가 공유하는 영역이니까, 클래스와 변수 정보 그리고 static으로 선언한 변수가 저장되는 공간이다.

3.2 힙 영역

Heap 영역에는 동적으로 생성된 객체가 저장되는 영역이다.

즉 힙 영역에는 new 연산을 통하여 동적으로 생성된 인스턴스 변수가 저장된다.

예를 들어, 클래스의 객체 그리고 배열등이 있다.

생성된 변수는 해당 객체가 소멸되기 전이나, GC가 정리하기 전까지는 이 영역에 남아있습니다.

쉽게 소멸되는 데이터가 아니다.

3.3 힙

힙 영역은 가비지 컬렉션의 대상이 되는 공간이다.

효율적인 가비지 컬렉션을 수행하기 위해서 더 세부적으로는 다섯 가지 영역으로 나뉘게 된다.

3.4 스택

지역 변수, 메서드의 매개 변수, 임시적으로 사용되는 변수, 메서드의 정보가 저장되는 영역

메서드의 호출이 종료되면 이 안에 선언된 변수들은 사라진다.

그러니까 주로 금방 사용되고 금방 사용이 끝나는 데이터가 저장되는 영역이다.

3.5 헷갈릴 만한 이슈

- 변수의 저장 방법

객체를 생성했다.

이렇게 생성한 객체를 참조하는 변수 p는 Stack에 저장이 된다.

그리고 동적으로 생성한 Person 객체는 Heap 영역에 저장이 된다.

- 변수의 타입 이해

Primitive Type은 boolean, byte, short, int, long, char, float, double이다.

이를 제외한 나머지가 바로 Reference Type이다.

이러한 변수들이 실행될 때 마다 스택에 쌓여서 넣었다 뺐다하면 비효율적이므로 스택이 아닌

Heap영역에 그 진짜 메모리를 저장하고

그 메모리를 참조하는 주소를 stack영역에 저장하는 것이다.

3.6 PC Register

PC 레지스터는 프로그램 카운터라고 

우리가 일반적으로 알고 있는 컴퓨터를 의미하는 것이 아니다.

그리고 운영체제를 공부한 분이 아는 우리가 일반적으로 아는 CPU 레지스터 내부에 있는

다음에 실행될 명령어의 주소를 저장하는 공간을 의미하는 것이 아니라

스레드가 어떤 부분을 어떤 명령어로 수행할지 저장하는 공간이다.

스레드가 시작될 때 생성되며 현재 수행중인 JVM의 명령어 주소를 저장하는 공간이다.

3.7 Native Method Stack

자바 프로그램이 컴파일되어 생성되는 바이트코드가 아닌

 실제 실행할 수 있는 기계어로 작성된 프로그램을 실행시키는 영역이다.

 

Runtime Data Area에 로딩된 클래스 파일이 Execution Engine을 통해 해석될 차례이다.

Execution Engine은 로드된 클래스 파일의 바이트 코드를 실행하는 엔진이다.

 

그리고 바이트 코드를 실행시키기 위해서는 

바이트코드를 컴퓨터가 이해할 수 있는 기계어로 바꾸는 작업이 필요하다.

여기서 두 가지의 방법이 있다.

Interpreter는 명령어를 한 줄 한 줄 해석하면서 실행한다.

그리고 JIT Compilter (Just In Time Compiler) 는 Interpreter의 단점을 해결하기 위한 방법으로 

Runtime 시간에 한꺼번에 변경하여 실행한다.

이제 이렇게 기계어로 해석된 것들이 이제 

Runtime Data Area에 배치되어 스레드 동기화나 가비지 컬렉션을 수행하게 된다.

마지막으로 Native Method Interface(JNI)와 

Native Method Library를 살펴보겠다.

Native Method Interface(JNI)는 

JVM에 의해 실행되는 코드 중 네이티브로 실행되는 것이 있다면

해당 네이티브 코드를 호출하거나 호출될 수 있도록 만든 일종의 프레임워크이다.

그리고 Native Method Libraries는 네이티브 메소드의 실행에 필요한 라이브러리이다.

 

감사합니다.

728x90
반응형
LIST
728x90
반응형
SMALL

*Youtube Link - https://www.youtube.com/watch?v=_23I6qDmCi4

 

1. 책

JVM은 C++ 코드입니다.

JVM 자체가 Native Code로 만들어집니다.

그래서 C++로 개발이 되었습니다.

 

Java는 C++ 

C++은 Pointer라는 Native를 갖고 있다. (RAM의 물리적 주소이다.)

그래서 참조형을 사용하면 물리 RAM에 직접 접근하는 것이다.

 

2. JVM 에 대한 추가 설명

"Microsoft processor specific -> Interface -> C, C++ -> COMPILER -> Assembly Language -> Assembler -> Machine Code"

"JAVA -> [Virtual Machine] -> Native codes -> Platform (os -> Micro pro processor -> Platform (AMD, ex)Intel))"

"Native codes -> Machine code"

 

C언어 및 C++언어는 Native codes이다.

마이크로소프트 프로세서가 있고, 그에 대한 인터페이스를 기반으로 C, C++로 코딩을 한다.

그에 반해 JAVA는 Virtual Machine이라는 것이 있어서 이러한 인터페이스 기능을 대신해준다.

JAVA의 Virtual Machine은 C++언어로 되어있다.

그리고 각 OS(AMD, 예로 Intel)로 맞는 Microsoft pro processor에 맞도록 된다.

그래서 os를 먼저 읽고, Native codes로 만들어진다.

그러면 이 Native codes가 Complier를 거쳐서 Assembly Language가 되고 

Assembler를 통해서 Machine Code가 만들어진다.

 

"Native codes has a knowledge to convert for any Platform."

"C, C++ are example of basic native codes."

C, C++언어는 Native codes이다. 그래서 어떤 플랫폼도 맞도록 Complie될 수 있도록 한다. 

Complier가 이를 가능하게 한다.

 

Hotspot JVM -> 힙에 어떻게 저장되는지

스택은 어떤지

 

3. Java Application의 구조

예를 들어서 GC 같은 경우 어떤 것을 사용해서 무엇을 했냐

JVM의 메모리 파티션 조정이 있다. 지연성이 올라가지 않으려면 어떻게 해야 하는가

Native codes에서 어떻게 바뀌어지고 

Java의 경우 모든 클래스들이 Object 클래스의 파생이죠. 

이 수준에서 논해지는 hash의 개념

JVM 디버그 수준에서 논하는 ID값 (테이블에서 이루어지는 과정)

객체를 어떻게 하는가

JVM (C++) -> Assembly(바이트 코드)

이 과정이 어떻게 이루어지는지

C++ 수준에서 보아야 한다.

 

바이트 코드 실행 엔진

-> 런타인 스택 프레임 구조

-> 스택 기반 바이트코드 해석 및 실행 엔진

 

컴파일과 최적화

 

컴파일러에 대한 지식이 있이 봐야 한다.

 

나중에 스레드 및 동시성에 대해 알아야 한다.

실행의 단위는 Thread이다.

K 수준의 Thread, Application Thread와 1:1 매핑이 된다.

 

스레드로 넘어가면 락 이야기가 나온다.

최적화에 대한 이야기가 나온다.

 

JVM 최적화에 대한 이야기이다.

 

여기서 C, C++ 언어를 알게 되면

기계어까지 가게 된다.

그런 관점에서 구조론을 논하다 보니 데이터베이스 현상에 대해서 논할 수 있다.

2차 메모리 같은 Disk에서 무언가가 걸어진다.

JVM으로 이어지면 컴파일러에 대해 이해를 해야 한다.

 

전공자의 기본기 이 다섯가지를 다 공부하고

보실 것을 추천을 드립니다.

 

감사합니다.

728x90
반응형
LIST

+ Recent posts