분류 전체보기

L4/L7 스위치의 대안, 오픈 소스 로드 밸런서 HAProxy 2016.03.21
static 2016.03.08
Java Code Conventions / 자바 코딩 규칙 2016.03.08
자바 메모리 누수에 대한 이해 IT 2016.03.08

L4/L7 스위치의 대안, 오픈 소스 로드 밸런서 HAProxy

2016. 3. 21. 15:10

L4/L7 스위치의 대안, 오픈 소스 로드 밸런서 HAProxy

: 2013.02.14
: |
: 92576

Ncloud에서 하드웨어로 구성된 기존의 로드 밸런서(load balancer)를 대체할 수 있는 솔루션을 찾던 중 소프트웨어 로드 밸런서인 HAProxy를 검토하게 됐습니다. HAProxy를 검토하면서 정리한 자료와 사내 개발용 Ncloud(ncloud.nhncorp.com) 서비스에 HAProxy를 적용한 사례를 공유하려 합니다.

HAProxy를 이해하기 위해서 우선 로드 밸런서의 기본 개념을 이해하고 HAProxy의 동작 방식을 알아보겠습니다. 그리고 HAProxy로 설계 가능한 구조를 알아보겠습니다.

오픈 소스 로드 밸런서 HAProxy

HAProxy는 기존의 하드웨어 스위치를 대체하는 소프트웨어 로드 밸런서로, 네트워크 스위치에서 제공하는 L4, L7 기능 및 로드 밸런서 기능을 제공한다. HAProxy는 설치가 쉽고 또한 환경 설정도 어렵지 않으므로 서비스 이중화를 빠르게 구성하고 싶다면 HAProxy를 추천한다.

로드 밸런싱이란?

로드 밸런싱이란 부하 분산을 위해서 가상(virtual) IP를 통해 여러 서버에 접속하도록 분배하는 기능을 말한다. 로드 밸런싱에서 사용하는 주요 기술은 다음과 같다.

NAT(Network Address Translation): 사설 IP 주소를 공인 IP 주소로 바꾸는 데 사용하는 통신망의 주소 변조기이다.
DSR(Dynamic Source Routing protocol): 로드 밸런서 사용 시 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념이다.
Tunneling: 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념으로, 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있다.

로드 밸런서 동작 방식

이제 일반적인 로드 밸런서의 동작 방식을 설명하고 HAProxy를 설명하겠다.

로드 밸런서의 동작을 간단하게 설명하면, 네트워크에서 IP 주소와 MAC 주소를 이용해 목적지(destination) IP 주소를 찾아가고 출발지로 되돌아오는 구조이다. 이 글에서는 4가지의 로드 밸런서 동작 방식을 설명하겠다. 일반적인 로드 밸런서의 동작을 참조하기 위한 것이므로 정확하게 이해하지 못해도 상관없다.

Bridge/Transparent Mode

사용자가 서비스를 요청하면 L4로 전달된 목적지 IP 주소를 real server IP 주소로 변조하고 MAC 주소를 변조해서 목적지를 찾아가는 방식이다.

요청 전달 시 변조
- 사용자 > L4 > NAT(IP/MAC 주소 변조) > real server - 사용자가 L4를 호출하면 중간에 NAT가 목적지 IP 주소를 real server IP 주소로 변조하고 MAC 주소도 변조한다.
응답 전달 시 변조
- real server > NAT > L4 > 사용자 - real server에서 L4를 거치면서 출발지(source) IP 주소를 L4 가상 IP 주소로 변조한다. 동일 네트워크 대역이므로 MAC 주소는 변조하지 않는다.

Router Mode

Bridge/Transparent Mode와 유사하지만 출발지(source) MAC 주소도 변조된다.

One Arm Mode

사용자가 real server에 접근할 때 목적지 IP는 L4 스위치 IP를 바라본다. L4에 도달하면 L4가 클라이언트에게 받은 목적지 IP 주소를 L4 IP 주소에서 real server IP와 real server MAC 주소로 변조한다. 되돌아가는 IP는 L4의 IP pool의 IP 주소로 변조한다.

DSR (Direct Server Return) Mode

사용자가 real server에 접근할 때 출발지와 목적지의 IP 주소를 변조하지 않고, L4에서 관리하는 real server의 MAC 주소 테이블을 확인해서 MAC 주소만 변조한다.

HAProxy 동작 방식

HAProxy는 기본적으로 reverse proxy 형태로 동작한다. 우리가 브라우저에서 사용하는 proxy는 클라이언트 앞에서 처리하는 기능으로, forward proxy라 한다. reverse proxy의 역할을 간단히 설명하면, 실제 서버 요청에 대해서 서버 앞 단에 존재하면서, 서버로 들어오는 요청을 대신 받아서 서버에 전달하고 요청한 곳에 그 결과를 다시 전달하는 것이다.

HAProxy의 동작 방식을 알아보고 HAProxy를 이용해서 어떤 구조로 확장할 수 있는지 알아보겠다.

HAProxy의 동작 흐름은 다음과 같다.

최초 접근 시 서버에 요청 전달
응답 시 쿠키(cookie)에 서버 정보 추가 후 반환
재요청 시 proxy에서 쿠키 정보 확인 > 최초 요청 서버로 전달
다시 접근 시 쿠키 추가 없이 전달 > 클라이언트에 쿠키 정보가 계속 존재함(쿠키 재사용)

haproxy1

그림 1 HAProxy 동작 방식

HAProxy HA(High availability) 구성

HAProxy는 기본적으로 VRRP(Virtual Router Redundancy Protocol)를 지원한다. HAProxy의 성능상 초당 8만 건 정도의 연결을 처리해도 크게 무리가 없지만, 소프트웨어 기반의 솔루션이기 때문에 HAProxy가 설치된 서버에서 문제가 발생하면 하드웨어 L4보다는 불안정할 수 있다. 따라서 HA 구성으로 master HAProxy에 문제가 생기는 경우에도 slave HAProxy에서 서비스가 원활하게 제공될 수 있는 구성을 알아보겠다.

다음 그림과 같은 구성에서는 가상 IP 주소를 공유하는 active HAProxy 서버와 standby HAProxy 서버가 heartbeat를 주고 받으면서 서로 정상적으로 동작하는지 여부를 확인한다. active 상태의 서버에 문제가 발생하면 standby HAProxy가 active 상태로 변경되면서 기존 active HAProxy의 가상 IP 주소를 가져오면서 서비스가 무정지 상태를 유지한다. 다만 1초 정도의 순단 현상은 발생할 수 있다.

haproxy2

그림 2 HAProxy 무정지 구성

HA로 설정된 HAProxy의 동작 흐름이 단일 HAProxy와 다른 점은 최초 접근 시 쿠키에 바로 서버 정보를 입력하지 않고 서버에서 jsessionid가 전달될 때 서버 정보를 합쳐서 전달한다는 것이다.

쿠키에 정보 추가 없고 X-Forwarded-For에 정보 추가
쿠키에 추가 없음
Jsessionid 추가
서버 정보 + jsessionid를 쿠키에 추가
쿠키에서 서버 판별 후 jsessionid만 전달

haproxy3

그림 3 HA 구성 시 동작 방식

L4 + HAProxy HA 구성 및 Global 환경에서 구성

HAProxy와 기존 하드웨어 스위치를 이용해서 더 확장된 형태의 고가용성 구조를 설계할 수가 있다. 다음과 같은 형태의 구성도 가능하다.

하드웨어 L4 + HAProxy

클라이언트에서 연결되는 부분은 가상 IP 주소 + L4의 구성으로 하드웨어 이중화를 구축하고, L4에서 서버 앞 단에 HAProxy를 구축해서 HAProxy를 더 확장할 수 있는 구조로 설계할 수 있다.

haproxy4

그림 4 L4 + HAProxy 구성

GSLB(Global Service Load Balancing) + HAProxy

global 서비스가 증가되면서 IDC 간 이중화 및 global 환경에서의 무정지 서비스를 위한 DR(Disaster Recovery, 재해 복구) 시스템 구축이 필수 요구사항이 되었다. GSLB + HAProxy를 이용하면 global한 무정지 서비스 구축이 가능하다.

GSLB 구축에 L4 스위치를 사용할 수도 있지만 GSLB 구성용 L4는 고가의 장비이다. 따라서 L4를 이용한 GSLB 대신 DNS(BIND)를 이용한 구축 형태는 다음과 같다.

클라이언트에서 DNS로 도메인 조회
근거리 IDC 정보 전달

haproxy5

그림 5 Global 환경에서 GSLB+HAProxy 구성

이상 로드 밸런서의 동작 원리와 HAProxy를 이용한 다양한 구축 방법에 대해서 알아보았다. 이제 실제 HAProxy를 설치하기 위한 옵션 및 설치 방법에 대해서 알아보겠다.

HAProxy Ncloud 적용 사례

사내 개발자용 Ncloud 시스템은 DNS에서 RR(Round Robin) 기능을 통해 이중화된 서비스로 운영하고 있었다. 그런데 DNS의 경우 팀에서 관리하는 시스템도 아니고 서버 증설 또는 제거를 위해서 매번 관리 시스템을 통해서 작업하는 것이 번거로웠다. 또한 HAProxy의 실제 적용을 테스트하기 위해서 우리가 관리하는 시스템에 적용했는데, 이 적용 및 운영 사례를 살펴보겠다.

사내 Ncloud 시스템의 DNS RR을 HAProxy로 교체

사내 Ncloud 시스템의 DNS RR을 HAProxy로 교체하여 <그림 6>과 같이 앞에서 설명한 HA 구성과 동일한 형태로 구성했다. 그 결과 기존 DNS로 구성할 때보다 서버 증설 및 삭제에 있어 유연성이 증가했으며 HA 구성으로 서비스 안정성도 높아졌다.

그런데 서버 반영 후 애플리케이션 서버에서 클라이언트 IP 주소를 찾아서 처리하는 로직에 문제가 발생했다. 확인 결과 사용자의 요청이 HAProxy를 거치면서 클라이언트 IP 주소 정보가 HAProxy의 정보로 변조되어 보이는 상황이었다.

이 문제가 발생하지 않도록 하기 위해서 HAProxy에서 제공하는 X-Forwarded-For 옵션을 적용하고 Apache 서에는 mod_rpaf 모듈을 설치해서 애플리케이션 서버가 HTTP 헤더에서 클라이언트 IP 주소를 조회하면 실제 클라이언트 IP 주소가 반환되도록 보완했다.

haproxy6

그림 6 HAProxy 적용 구조

실제 적용 후 서버 L7 check가 잘 되고 있는지 HAProxy가 제공하는 어드민 페이지에서 확인했고, 클라이언트 IP 주소 문제 외에 별다른 이슈는 발생하지 않았다.

haproxy7

그림 7 HAProxy 어드민 페이지

HAProxy 성능

Ncloud는 동시 접속자가 많은 시스템이 아니라 성능에 대해 크게 문제될 부분이 없었지만 HAProxy가 설치되는 서버의 사양에 따라 어느 정도 성능이 제공되는지 확인하기 위해 성능을 측정했다. 여기에서는 nGrinder(http://www.nhnopensource.org/ngrinder/) 테스트 결과와 해외 사례를 공유한다.

1. 해외 운영 사례

서버 사양(저사양): Dell PowerEdge 2850, Intel PCI3 4x Gigabit Fiber card (CPU 1.6GHz dual core x 1)
제공 서비스: 영화 다운로드 서비스
결과: 일별 2.47TB 전송 + 81일 동안 운영

2. nGrinder 테스트

환경: HAProxy (1core), apache 서버 2대
결과: 6,603 TPS

haproxy8

그림 8 nGrinder 테스트 결과

3. 해외 성능 사례

듀얼 CPU 환경에서 초당 2만 세션까지 연결 가능 -> CPU 성능이 높아지면 연결 가능 세션 수 증가
초당 1만 건 세션 연결 시 응답에 100밀리초(ms) 소요 -> 최대 연결 개수는 하드웨어의 RAM과 file descriptor에 의해 결정됨 -> 세션당 16KB 사용 시 6만 세션당 1G RAM 필요

haproxy9

그림 9 해외 성능 테스트 사례(이미지 출처: http://haproxy.1wt.eu/#perf)

HAProxy 설치 및 옵션

HAProxy의 중요 옵션과 단점에 대해서 간단하게 알아보겠다. 자세한 설치 방법 및 서비스에 사용되는 설정은 마지막에 설명해 놓았으니 실제 설치가 필요한 경우에 참고하기 바란다.

HAProxy 운영 시 필요한 옵션

HAProxy의 경우 튜닝 옵션을 비롯하여 매우 많은 옵션을 지원하므로 여기에서는 실제 구축 시 필요한 옵션만 간략하게 알아보겠다.

옵션을 변경하려면 haproxy.cfg 파일을 수정한다. 실제 수정 방법은 설치 방법에서 설명한다. 더 자세한 설명이 필요하면 다음 웹 페이지에서 확인하기 바란다.

HAProxy 설정 매뉴얼: http://cbonte.github.com/haproxy-dconv/configuration-1.4.html

HAProxy 옵션

다음은 전역 옵션(global) 섹션과 기본 옵션(defaults) 섹션, 프록시 옵션 섹션(listen)의 주요 옵션에 관한 설명이다.

global # 전역 옵션 섹션
- daemon: 백그라운드 모드(background mode)로 실행
- log: syslog 설정
- log-send-hostname: hostname 설정
- uid: 프로세스의 userid를 number로 변경
- user: 프로세스의 userid를 name으로 변경
- node: 두 개 이상의 프로세스나 서버가 같은 IP 주소를 공유할 때 name 설정(HA 설정)
- maxconn: 프로세스당 최대 연결 개수
Defaults # 기본 옵션 섹션
- log: syslog 설정
- maxconn: 프로세스당 최대 연결 개수
listen webfarm 10.101.22.76:80 : haproxy name ip:port
- mode http: 연결 프로토콜
- option httpchk: health check
- option log-health-checks: health 로그 남김 여부
- option forwardfor: 클라이언트 정보 전달
- option httpclose: keep-alive 문제 발생 시 off 옵션
- cookie SERVERID rewrite: 쿠키로 서버 구별 시 사용 여부
- cookie JSESSIONID prefix: HA 구성 시 prefix 이후에 서버 정보 주입 여부
- balance roundrobin: 순환 분배 방식
- stats enable: 서버 상태 보기 가능 여부
- stats uri /admin: 서버 상태 보기 uri
- server xvadm01.ncli 10.101.22.18:80 cookie admin_portal_1 check inter 1000 rise 2 fall 5: real server 정보(server [host명] [ip]:[port] cookie [서버쿠키명] check inter [주기(m/s)] rise [서버구동여부점검횟수], fall [서비스중단여부점검횟수])

balance 옵션

로드 밸런싱의 경우 round robin 방식을 일반적으로 사용하지만 다른 여러 방식이 있다. 옵션에 적용할 수 있는 로드 밸런싱 알고리즘은 다음과 같다.

roundrobin: 순차적으로 분배(최대 연결 가능 서버 4128개)
static-rr: 서버에 부여된 가중치에 따라서 분배
leastconn: 접속 수가 가장 적은 서버로 분배
source: 운영 중인 서버의 가중치를 나눠서 접속자 IP를 해싱(hashing)해서 분배
uri: 접속하는 URI를 해싱해서 운영 중인 서버의 가중치를 나눠서 분배(URI의 길이 또는 depth로 해싱)
url_param: HTTP GET 요청에 대해서 특정 패턴이 있는지 여부 확인 후 조건에 맞는 서버로 분배(조건 없는 경우 round robin으로 처리)
hdr: HTTP 헤더 에서 hdr(<name>)으로 지정된 조건이 있는 경우에 대해서만 분배(조건 없는 경우 round robin으로 처리)
rdp-cookie: TCP 요청에 대한 RDP 쿠키에 따른 분배

HAProxy 1.4.22 단점 - SSL 미지원

1.4.22 안정화 버전에서는 기본 기능으로 SSL을 지원하지 않고 있다. 1.4.22 버전에서 HTTP와 HTTPS를 같이 지원하려면 Apache + mod_ssl + HAProxy를 구성해서 Apache를 reverse-proxy-cache로 사용한다. only HTTPS 모드이면 stunnel을 설정하고 사용할 수 있다.

현재 개발 중인 1.5_dev 버전은 에서는 정식으로 SSL을 지원할 예정이다.

HAProxy 설치 및 config 수정

HAProxy 설치를 위한 소스 파일 다운로드와 설치 절차는 다음과 같다.

예제 1 HAProxy 소스 다운로드 및 설치 절차

$ wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.22.tar.gz
$ tar xvfz haproxy-1.4.22.tar.gz
$ cd harproxy-1.4.22
$ make TARGET=linux26 ARCH=x86_64
$ make install
$ cd examples
$ cp haproxy.init /etc/rc.d/init.d/haproxy
$ chmod 755 /etc/rc.d/init.d/haproxy
$ mkdir -p /etc/haproxy/
$ cp /생성위치/haproxy-1.4.22/examples/haproxy.cfg /etc/haproxy/
$ mkdir -p /etc/haproxy/errors/
$ cp /생성위치/haproxy-1.4.22/examples/errorfiles/* /etc/haproxy/errors/
$ cd /usr/sbin
$ ln -s /usr/local/haproxy/sbin/haproxy haproxy
$ vi /etc/haproxy/haproxy.cfg

haproxy.cfg 파일은 다음 설정 예제를 참고해서 수정하면 된다.

예제 2 HAProxy 환경 설정 예제

#서버 정보
#LB ip         10.101.22.33
#server-1 10.101.27.49
#server-2 10.101.26.50

global  
        log 127.0.0.1   local0
        log 127.0.0.1   local1 notice
        maxconn 4096
        uid 99
        gid 99
        daemon
        log-send-hostname
        #debug
        #quiet

defaults  
        log     global

listen  webfarm 10.101.22.33:80  
        mode http
        option httpchk GET /l7check.html HTTP/1.0
        option log-health-checks
        option forwardfor
        option httpclose
        cookie SERVERID rewrite
        cookie JSESSIONID prefix
        balance roundrobin
        stats enable
        stats uri /admin
        server  xvadm01.ncli 10.101.27.49:80 cookie admin_portal_1 check inter 1000 rise 2 fall 5
        server  xvadm02.ncli 10.101.26.50:80 cookie admin_portal_2 check inter 1000 rise 2 fall 5
$ /etc/init.d/haproxy start

마치며

HAProxy는 네트워크 담당자가 아닌 개발자들에게는 관심 없는 분야의 기술일 수 있다. 그렇지만 모바일 환경이 발달하면서 빠르고 유연한 확장성은 필수 요소로 생각해야 한다. 최초 서비스 구축 시 확장성을 고려해서 L4/L7 스위치 분산까지는 고려할 수 있겠지만 지역간 분산(GSLB 구성)을 고려해서 설계하는 것은 일부 업체를 제외하고는 비용 및 경험 부재로 쉽지 않은 것이 사실이다. 하지만 'DNS + HAProxy + 클라우드 서비스'로 조합하면 적은 비용으로도 동일한 수준으로 구축할수 있다. 그래서 HAProxy의 개념과 서비스 구축 방안 정도는 미리미리 습득하기를 권장한다.

참고 자료

HAProxy Configuration Manual 1.4.22-9: http://cbonte.github.com/haproxy-dconv/configuration-1.4.html
HAProxy 1.5-dev12 support SSL : http://blog.exceliance.fr/2012/09/04/howto-ssl-native-in-haproxy/
HAProxy Performance : http://haproxy.1wt.eu/#perf
Load Balancer : http://blog.loadbalancer.org/?a=1
KeepAlived : http://keepalived.org/
Stunnel : https://www.stunnel.org/index.html
Openssl : http://www.openssl.org/

LIST

static

2016. 3. 8. 17:51

static

static 키워드는 클래스 차원의 변수와 메소드를 만들 때 사용한다.
정적(static)이란 클래스가 로딩될 때 결정된 메모리 공간이 변하지 않음을 의미한다.
static 변수와 메소드는 객체를 생성하지 않고도 아래와 같이 사용할 수 있다.

클래스명.static변수
클래스명.static메소드()

메인 메소드가 static 메소드이다.
프로그램을 실행하면 클래스 로더가 관련 클래스를 클래스 패스에서 찾아서 메모리에 로딩한다.
그다음 JVM이 java 다음에 나오는 시작 클래스에서 메인 메소드를 실행한다. 자바 프로그램이 실행되기 위해서는 클래스가 우선 메모리에 로딩되어야 한다.
클래스 로더(Class Loader)가 클래스를 찾아서 메모리에 로딩한다.
클래스가 로딩되는 메모리 공간과 객체가 활동하는 메모리 공간은 다르다.
객체가 할당되는 공간은 JVM의 힙heap 메모리 영역이다. new가 실행될 때마다 힙 메모리에 객체의 인스턴스 변수를 위한 공간이 할당된다. 클래스가 메모리에 로딩될 때 static 변수와 static 메소드를 위한 공간이 할당된다.
한번 메모리에 공간이 할당되면 인스턴스 변수와 달리 객체가 생성될 때마다 메모리 공간이 할당되지 않는다.
static 메소드 안에서는 인스턴스 변수를 쓸 수 없다. 만들지도 않는 객체의 속성을 참조한다는 것은 말이 되지 않기 때문이다.
학생 클래스에 메인 메소드를 추가하고 다음과 같이 구현하면 컴파일 에러를 만나게 된다.

public static void main(String[] args) {
    absentNum++;
}

그 반대의 경우인 인스턴스 메소드 내에서 static 변수나 static 메소드를 쓰는 것은 문제가 없다.
결석, 지각, 조퇴하면 벌금을 내도록 했다고 가정하자.
학생은 결석 3천원, 지각이나 조퇴는 천원의 벌금을 벌금통에 넣어야 한다.
여기서 벌금통을 코드로 어떻게 구현하면 되겠는가?
벌금통은 학생 한명당 하나씩 있는 것이 아니다.
단 하나이면서 모든 학생이 공유한다.
벌금통이라는 클래스를 새로 만들고 이 클래스에 싱글톤 패턴을 적용해도 된다.
더 좋은 방법은 벌금통을 모든 객체가 공유하는 변수인 static 변수로 만드는 것이다.

public class Student {
    static int penaltyBin; //벌금통

    public void absent() {
        this.absent++;
        Student.penaltyBin += 3000;
    }
    //..중간 생략..
}

정적 변수 예제

package net.java_school.user;

public class User {

    public static int total; //접속된 회원 수
    private String id;
    
    public User(String id) {
        this.id = id;
        total++;
    }

    public static void main(String[] args) {
        User user1 = new User("hong1440");
        User user2 = new User("im1562");
        User user3 = new User("jang1692");
        
        System.out.println("접속된 회원수 : " + User.total);
    }

}

접속된 회원수 : 3

싱글톤 패턴(Singleton pattern)

객체가 단 하나만 만들어져야 할 때 사용하는 디자인 패턴이 싱글턴 패턴이다.
static 변수가 초기화되는 시점은 클래스가 로딩될 때이다.

싱글톤 패턴을 적용한 예제를 만들어 보겠다.
가정집에는 식탁이 하나만 있어야 한다.
식탁이 여러개 있어서 각자 식사 한다면 이상적인 가정에 방해가 될 수 있다.
식탁 테이블을 싱글톤 패턴으로 객체가 하나만 생성되도록 클래스를 설계한다.

package net.java_school.house;

public class CookTable {

    private static CookTable instance = new CookTable();
    
    public static CookTable getInstance() {
        return instance;
    }
    
    private CookTable() {}
    
    //..중간 생략..
  
}

클래스 정보가 클래스 로더에 의해 로딩될 때 static 변수는 초기화 된다.
CookTable 의 static 변수 instance 가 초기화 되기 위해
CookTable 객체가 힙에 생성되고 참조값은 instance 에 할당된다.
이 값은 공개된 getInstance() 를 통해 얻을 수 있다.
하나뿐인 생성자의 접근자를 private 로 지정하여 외부에서 생성자를 호출 못하게 한다.
이렇게 구현하면 프로그램 종료시까지 CookTable 인스턴스는 하나로 유지된다.

초기화 순서

변수는 메모리 공간이 할당될 때 초기화된다.
이때 초기값이 없다면 불린형은 false, 숫자형은 0 에 준하는 값으로, 레퍼런스 형은 null로 초기화된다.
static 이 아닌 멤버 변수가 초기화되는 시점은 객체가 생성될 때이다.

초기화 순서는 static 변수 -> 인스턴스 변수 -> 생성자 이다.
static 변수와 static 블록은 같은 레벨이다. 먼저 나온 것이 먼저 초기화된다.
인스턴스 블록의 경우 컴파일러가 인스턴스 블록의 구현부를 모든 생성자의 마지막 라인에 추가한다.
다음 문제의 결과를 예측해본다.
A.java

package net.java_school.classvar;

public class A {

    public A() {
        System.out.println("A() 생성자 실행");
    }
        
}

B.java

package net.java_school.classvar;

public class B {
    private A a = new A();
    
    {
        System.out.println("B 인스턴스 블록 실행");
    }
    
    static {
        System.out.println("B static 블록 실행");
    }
    
    private static B b = new B();

    private B() {
        System.out.println("B() 생성자 실행");
    }
    
    public B(int a) {
        System.out.println("B(int) 생성자 실행");
    }

    public static void main(String[] args) {
        new B();
        new B(1);
    }
        
}

B static 블록 실행
A() 생성자 실행
B 인스턴스 블록 실행
B() 생성자 실행
A() 생성자 실행
B 인스턴스 블록 실행
B() 생성자 실행
A() 생성자 실행
B 인스턴스 블록 실행
B(int) 생성자 실행

참고

LIST

Java Code Conventions / 자바 코딩 규칙

2016. 3. 8. 16:50

Java Code Conventions / 자바 코딩 규칙

Java_Code_Conventions____.pdf

LIST

자바 메모리 누수에 대한 이해 IT

2016. 3. 8. 16:45

자바 메모리 누수에 대한 이해 IT

2005.06.26. 17:35

http://blog.deogtae.com/20014163264

번역하기 전용뷰어 보기

가비지 컬렉션은 프로그램의 관점에서 보아야한다. 프로그램에서 현재
도달 불가능한 객체들은 모두 쓰레기 객체이며, 이와 같은 노드 그래프를
염두에 두기 전에 루트 노드가 어떤 의미인지를 파악해야 한다. 눈에
보이지는 않지만 가상적으로 프로그램이라는 노드가 있다고 생각할 수
있으며, 이 프로그램이라는 노드로 부터 현재 직접 참조될 수 있는 상황에
있는 노드들이 모두 루트 노드들이다. 따라서, 루트 노드들은 쓰레기가 될
수 없다. 루트 노드들이 아닌 것은 모두 루트 노드들을 통하여 참조를
따라가서 참조될 수 있을 뿐이다.

좀더 일반화시켜 설명하면,
여기서 노드가 꼭 객체를 의미하는 것은 아니며, 프로그램일 수도 있고,
전역 변수나 필드가 될 수도 있다.
그러나, 그 개념은 어디든 통용될 수 있으며, 어떻게 그 개념을 실제 프로그래밍
언어에 매핑시키고 구현을 하느냐에 따라 달라질 뿐이다.
가령, 자바 프로그램의 경우, 루트 노드는 현재 존재하는 모든 스레드 스택내의
객체 참조 변수들과 static 참조 변수들이라고 일반적으로 설명하며,
프로그램에서는 이들을 통해서만 객체에 접근할 수 있기 때문이다.

그러나, 더 엄밀하게는 루트 노드는 프로그램 (더 정확히는 프로세스)라고 볼 수 있고,
스레드 스택 변수나 static 변수는 프로그램을 단순히 대리하여 다른 객체를 참조한다고
모델링할 수도 있으며, 이와같이 모델링하는 것이 더 근본적이고 명확하다.
이는 객체가 다른 객체를 직접 참조하는 것이 아니라 필드를 통하여 참조하는 것과
같은 이치이다. 즉, 필드가 객체를 대리하여 타 객체를 참조하는 것처럼
그과 같은 변수가 프로그램을 대리하여 타 객체를 참조하는 것이다.
혹은, 현재 스레드 스택 변수와 static 변수에 의해 직접 참조되는 객체들을
루트 노드로 할 수도 있다.
어떻게 개념적으로 매핑하든 그 결과는 동일하며, garbage collection에 대하여
개념적으로 가장 근본적인 설명은 프로그램에 의해 직간접적으로 참조될 수 없는 객체를
자동으로 제거하는 것이다.

스레드 스택 변수나 static 변수를 통하여 직간접적으로 참조될 수 없는 객체는
확실하게 쓰레기 객체이며 garbage collector에 의해 자동으로 제거될 수 있다.
그러나, 스레드 스택 변수나 static 변수를 통하여 참조될 수 있는 객체라
할지라도 논리적으로는 참조 불가능할 수 있다.
이는 reference counting이건 mark and sweep이건 동일하다.
그러나, 현재 기술로는 논리적으로 참조 불가능한 것 까지 기계적으로 찾아내지 못하고
그와 같이 명확한 부분만 자동화되어 있는 것이다.
논리적으로 참조 불가능한 것 까지 찾아내려면 인공지능 기술 혹은 이에 준하는
기술이 들어가야 한다.
그래서, 현재로서는 이를 해결하기 위해서 논리적으로 참조 불가능한 객체들의 참조들을
프로그래머가 끊어주는 처리를 해주어서 기계적으로 스레기 수집될 수 있는 상태로 만들어
주어야 하는 것이다.

이러한 이유로, 현재 소프트웨어 기술은 garbage collection 기법을 무엇을 사용하든
프로그래밍 언어를 무엇을 사용하든 memory leak 문제의 상당 부분이 여전히
프로그래머의 손에 남겨져 있는 것이며, 소프트웨어 기술이 발전할수록 프로그래머의 부담을
조금씩 경감시켜줄 수 있으나 완전히 없애주지는 못한다.

[출처] 자바 메모리 누수에 대한 이해|작성자 김덕태

LIST

PREV 이전 1 ···17 18 19 20 21 22 23 ···29 NEXT 다음

iTouch - Programing story

분류 전체보기