1 |
|
1 | // input |
1 | // #0 |
500일 때 최대 500^2 = 250000(25만)의 경우의 수가 나온다. 물론 재귀함수를 사용하면 이보다 더 많은 함수 호출이 일어나 시간초과가 발생할 것이다.
6개월 전에 풀었던 것을 다시 풀어보려니…생각이 안난다.
dp[a][b]
1 |
|
1 |
|
1 | ex) 현재 193425786 (0대신 9를 해야 각 자릿 수가 모두 채워진다. 0123...으로 하면 0이 사라짐) |
아래 코드에서 dist.count(next_num) == 0 대신 dist[next_num] == 0 을 하면 틀리다.
dist[해당 수]에는 이동 횟수가 들어있고 dist.count(해당 수)는 해당 경우의 수가 몇 번 나왔는지 알려주기 때문이다. map에서 해당 키, 값을 넣어주지 않았는데 바로 해당 키에 대한 값을 참조하려고(dist[next_num] == 0) 하면 제대로 연산이 수행되지 않을 것이다.
1 |
|
1 |
|
2편에서는 CD에서 무중단 배포까지 구축한다.
(1편에서는 Github Push 후에 Jenkins가 자동으로 빌드되도록 설정하였다.)
배포를 위해 scp를 사용하여 Jenkins에 있는 프로젝트 코드를 NAVER Cloud 서버에 복사해야 한다.
Node.js 기반의 프로젝트는 Tomcat과 같은 WAS(웹 서버+웹 컨테이너)가 존재하지 않아 ssh로 접속, scp로 파일을 주고 받는 작업으로 비교적 간단히 배포할 수 있다.
1 | ssh-keygen -t rsa |
키가 생성되면 authorized_keys, id_rsa, id_rsa.pub, known_hosts 가 생성되어 있는 것을 볼 수 있다.
scp로 파일을 주고 받는다 하였는데 이때 복사 받을 서버의 접속 비밀번호를 알아야 한다. 그렇게되면 복사할 때마다 매번 비밀번호를 요구하여 자동화 배포는 불가능하게 된다.
이를 해결하기 위해 위의 4개의 키를 이용한다.
Jenkins에서는 NAVER Cloud 서버를 호스트로, NAVER Cloud 서버에서는 Jenkins 서버의 공개 키를 허가받은 키로 등록한다. 이러면 비밀번호를 요구하지 않고 자동화 배포가 가능하다.
1 | ssh-keyscan -H (NAVER CLOUD 서버)ip >> ~/.ssh/known_hosts |
NAVER Cloud 서버의 authorized_keys
1 | vi ~/.ssh/authorized_keys |
scp로 테스트하기
접속 비밀번호를 요구하지 않았다면 성공이다.
이제 프로젝트가 배포되는 NAVER Cloud 서버에서 설정해야 할 부분이다.
(*Docker 및 NGINX 설치는 생략한다.)
ssh로 서버에 접속하고 Dockerfile을 다음과 같이 작성한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15FROM 이미지 환경
MAINTAINER 개발자
VOLUME 호스트와 공유할 폴더
RUN mkdir -p /app
WORKDIR /app
COPY ./프로젝트 소스코드 폴더/ /app
RUN npm install
CMD npm start
그 다음은 패키지 파일들을 설치하고 서버를 실행한다.
docker image build -t 도커이미지이름 .를 입력하여 이미지를 빌드한다.
docker-compose(컨테이너 관리)를 설치하여 편하게 컨테이너를 설정한다.
여기서 blue-green 배포 방식이 사용되는데, 이는 무중단 배포 구축을 위함이다.
1
2
3
4
5
6
7
8
9version: '2'
services:
linking-server:
image: 빌드한 도커 이미지
volumes:
- ./deploy:/deploy/linking
ports:
- "NAVER Cloud 서버 포트:컨테이너 포트"
image: 아까 빌드한 이미지 이름을 작성한다.
volumes: host 폴더와 컨테이너 폴더를 설정하여 공유한다.(심볼릭 링크와 비슷한 개념이라고 한다.)
ports: host 포트와 컨테이너 포트 순으로 작성하여 포트 포워딩 설정을 한다.
1 |
|
docker-compose -p ${DOCKER_APP_NAME}-blue -f docker-compose.blue.yml up -d를 입력하여 blue 컨테이너를 먼저 생성해준다.
docker ps -a로 컨테이너가 잘 실행되고 있는지 확인할 수 있다.
다음은 NGINX로 blue, green의 로드밸런싱을 설정해 주어야 한다.
vi /etc/nginx/sites-available/linking-server를 입력하여 다음과 같이 작성한다.
1
2
3
4
5
6
7
8
9
10
11
12
13# Load Balancing
upstream linking-server {
least_conn;
server 127.0.0.1:1025 weight=5 max_fails=3 fail_timeout=10s;
server 127.0.0.1:1026 weight=10 max_fails=3 fail_timeout=10s;
}
server {
listen 1024;
server_name NAVER Cloud 서버 아이피;
location / {
proxy_pass http://linking-server;
}
}
그런 다음 아래 명령어로 이 파일을 /etc/nginx/sites-enabled 디렉터리에 링크해준다.
sudo ln -fs /etc/nginx/sites-available/linking-server /etc/nginx/sites-enabled/
마지막으로 sudo nginx -t 명령어로 문법 이상 유무를 확인하고 이상이 없을 경우, systemctl stop nginx 명령어로 NGINX를 종료한 후에 systemctl start nginx 로 다시 시작한다.
여기서 마지막으로 한 가지 해야할 것은 ACG 설정이다.
NAVER Cloud Platform 콘솔에서 1024포트를 열어준다. 위에서 blue, green 모두 다른 포트지만 NGINX를 통해 1024 포트로 로드 밸런싱 되기에 사용자는 이를 통해 접근할 수 있다.
(보통 백엔드와 프론트엔드를 분리하면서 프로젝트를 진행하고 있다면 프론트엔드는 80포트를 사용하는게 좋다. 80이 기본 포트라 생략 가능하므로)
이것으로 NAVER Cloud 서버에서의 설정은 끝났다.
이제 마지막 Jenkins에서 빌드할 때 설정을 해주어야 위에서 설정한 무중단 배포가 자동화된다.
1 |
|
1) Jenkins가 빌드 동안 해당 서버에 접속하여 원래 있던 애플리케이션 코드를 삭제한다.
2) 빌드된 파일을 해당 서버에 복사한다.
3) 해당 서버에 다시 접속하여 새로 복사된 파일을 토대로 도커 이미지를 빌드한다.
4) 배포 스크립트를 실행한다.
위와 같은 과정이 일어나고 지금까지 설정한 것들이 모두 자동화되어 무중단 배포까지 진행된다. 이를 이제 Jenkins 프로젝트 관리에서 실행하도록 한다.
추가로 프로젝트에서 보이는 Embeddable Build Status를 클릭하면 마크다운 형식으로 Github 레포지토리에 빌드 상태바를 보이게 할 수 있다.
마지막으로 팀원들이 빌드 상태(시작, 실패, 성공)을 알고 싶을 때 Slack을 통해 알림을 받도록 할 수도 있다.
1편에서 이미 관련 플러그인을 설치하였기에 바로 설정이 가능하다.
설정을 하고 나면 Jenkins 프로젝트에서 빌드 후 조치에 알림 받을 내역을 설정할 수가 있게 된다.
이것으로 CI/CD 무중단 배포 환경 구축을 마친다.
Java에서 모든 것은 pass-by-value입니다. 참조가 아닌 값에 의해 호출됩니다.
stackoverflow에서 찾은 예제로 설명드리겠습니다.
1 | Cat myCat = new Cat("Rover"); |
Cat 객체의 주소를 42라고 가정하겠습니다. 42가 메소드에 넘겨지겠죠?
foo 메소드가 다음과 같다면,1
2
3
4
5public void foo(Cat someCat) {
someCat.setName("Max"); // 1.
someCat = new Cat("Fifi"); // 2.
someCat.setName("Rowlf"); // 3.
}someCat 은 주소값 42를 갖게 됩니다.
someCat은 42라는 주소에 해당하는 Cat을 가리킵니다.someCat의 이름은 Max가 됩니다.)someCat은 74라는 주소에 해당하는 Cat을 가리킵니다.someCat의 이름은 Rowlf가 됩니다.)이제, 메소드가 끝났습니다. myCat은 변경되었을까요?
정답은 “변경되지 않았다.” 입니다.myCat은 여전히 주소값 42를 갖고 있습니다. 하지만 주목해야 할 점은 “이름은 Max로 변경되었다.” 라는 것입니다.
C 언어를 공부하셨던 분들이라면 C와 유사하지만 다르다 라는 것을 느끼셨을 겁니다. C와 마찬가지로 주소값이 전달되지만, C와 다르게 포인터가 가리키는 곳을 변경할 수 없습니다.
위 코드를 다시 살펴보겠습니다.
1 | public void foo(Cat someCat) { |
myCat은 Rowlf라는 이름일텐데 Max이기 때문입니다.1 | public void foo(Cat someCat) { |
다음 예시를 보시면 명확하게 이해가 되실 겁니다.
1 | public class Main { |
1 | Foo f = new Foo("f"); |
위에서 설명했던 대로 f는 주소값을 가지고 타입이 Foo이고 속성이 f인 객체를 가리킵니다.
1 | public static void chanageReference(Foo a) |
a는 Foo 타입으로 선언되어 있고 null로 초기화 되어 있습니다.
1 | changeReference(f); |
f를 인자로 넘겨주어 a는 f와 동일한 주소값을 갖게 됩니다. 동일한 주소값이니 똑같은 곳을 가리키고 있는 것을 확인할 수 있습니다.
1 | Foo b = new Foo("b"); |
b는 주소값을 가지고 타입이 Foo이고 속성이 b인 객체를 가리킵니다.
1 | a = b; |
b의 주소값을 a에 할당하게 되어 a는 b가 가리키는 곳을 가리키게 됩니다.
1 | modifyReference(Foo c) { } |
f를 인자로 넘겨주어 c는 f의 주소값을 받게 됩니다. 당연히 f가 가리키는 곳을 가리키겠죠?
1 | c.setAttribute("c"); |
c가 가리키고 있는 객체의 속성을 c로 변경합니다. c와 f는 동일한 것을 가리키기에 f가 가리키는 객체의 속성은 c가 되는 것입니다.
call by reference 였다면 f의 주소값을 c나 a가 받았겠죠? 그렇다면 위에 a = b가 되었을 때 f도 바뀌었을 것입니다. 하지만 call by value이기 때문에 f, c, a, b 모두 각각 따로 존재하고 값만 전달 받고 있습니다.
Java에서는 모두 값을 전달하는 pass-by-value라는 것을 기억하시면서 이번 글을 마칩니다.
[Reference]
Java에서 null을 다루는 방법이란 흔히 NullPointerException을 피하도록 코드를 작성하는 것입니다.
먼저 null을 창안한 “토니 호어”는 null을 10억 달러짜리 실수라고 말하였습니다.
왜 그렇게 표현하였을까요?
관계가 없음을 나타내는 null은 모든 타입의 멤버가 될 수 있고 이 때문에 참조 변수 사용 시 널을 확인해야 합니다. 그렇지 않으면 NullPointerException을 보게 될 것이고 이는 실제로 SW 결함 통계에서 상당히 많은 부분을 차지하고 있습니다.
null 값을 갖는 변수는 JVM 메모리에서 참조하는 값이 없으면 해시 코드는 항상 0입니다. 즉, 힙 영역에 데이터를 생성하지 않았음.
그럼 이제 몇 가지 방법을 통해 null을 다루는 방법을 알아보겠습니다.
1 | Object unknownObject = null; |
null을 갖는 객체를 참조하려고 하면 NullPointerException이 발생하기에 위와 같이 사용하는게 안전합니다.
null을 갖는 객체에서 toString()을 호출하면 NullPointerException을 보신 경험이 있을 겁니다.(저만 그런가요?) 그렇기에 null을 반환하는 valueOf()를 사용하는게 좋습니다.
Null safe methods와 classes 관련 documentation을 보는게 가장 정확합니다. (당연한 소리?!)
Null safe method의 가장 흔한 예가 StringUtils 메소드로 아래처럼 코드를 작성해도 문제가 없습니다.
1 | System.out.println(StringUtils.isEmpty(null)); |
null이 아닌 EMPTY_LIST와 같이 비어있는 것을 표시하는 것을 사용하여 null 반환하지 않도록 합니다.
1 | public List getOrders(Customer customer){ |
메소드가 null safe인지 아닌지를 annotation을 사용하여 표시하는 것이 좋습니다. 그래야 컴파일러가 여러분이 미처 확인하지 못 한 또는 굳이 확인할 필요가 없는 부분에서 null check를 하도록 도와줄 수 있습니다.
1 | public class Employee |
만약 wrapper 클래스 객체가 null이라면, autoboxing은 NullPointerException에 취약할 수 밖에 없습니다.
다음 코드에서 doyun이라는 객체가 phjone number가 없다면 null을 리턴하지 않도록 해야 합니다. 그렇지 않다면 NullPointerException을 보게 될 것입니다.
1 | Person doyun = new Person("Doyun"); |
NullPointerException은 대부분 불완전한 정보나 요구되는 의존성을 모두 충족시키지 않고 객체가 생성되었을 때 발생합니다.
그렇기에 이를 피하는 방법만으로도 null을 다룰 수 있습니다. 예를 들어 Employee라는 객체는 id와 name 값이 없으면 생성될 수 없게 하고 옵션으로 phone number 값을 가질 수 있습니다.
단 여기서 phone number 값이 없다면 null을 리턴하지 않고 0과 같은 default 값을 리턴하도록 해야 합니다.
도메인 객체(Customers, Order와 같은)를 저장하기위해 DB를 사용하는 경우 DB 자체에서 null 제약 조건을 정의해야 합니다. (데이터의 무결성 보장 때문에)
DB에서 이런 제약 조건을 유지하는 것만으로 Java code에서 null check를 줄일 수 있습니다.
이미 DB에서 해당 필드가 null 값을 가질 수 있는지 없는지 확인하기에 Java code 내에서 불필요한 null 체크를 최소화할 수 있습니다.
1 | public abstract class Employee { |
1 | public class CurrentEmployee extends Employee { |
1 | public class NullEmployee extends Employee { |
1 | public class EmployeeFactory { |
NullPatternTest.java
1 | public class NullPatternTest { |
이렇게 하면 null 체크를 최소화하여 NullPointerException을 피할 가능성이 높아지고 코드가 간단해집니다.
다만, 새로운 메소드를 추가할 때마다 Null 객체 클래스에서도 이를 오버라이드해야 하기에 유지보수가 힘들 수도 있습니다.
이상으로 Null 다루기 편을 마치겠습니다. - 추가할 부분이 있으면 추가하겠습니다.
먼저 String 클래스와 StringBuffer 클래스의 차이점을 알아보겠습니다.
위 차이점 중에서 StringBuffer의 1, 2번 특징 덕분에 JVM 메모리를 보다 효율적으로 사용할 수 있습니다. 이에 대해 구체적으로 알아보겠습니다.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16public String getDescription()
{
String description = "Title: ";
description += "String ";
description += "VS ";
description += "StringBuffer\n";
description += "Content: ";
description += "Difference ";
description += "between ";
description += "String ";
description += "and ";
description += "StringBuffer ";
description += "is ";
description += "~~~\n";
return description
}
위와 같은 메소드가 있을 때 JVM 메모리에 생성되는 객체들은 다음과 같습니다.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21// 순서대로
1. Title:
2. Title: String
3. Title: String VS
4. Title: String VS StringBuffer
5. Title: String VS StringBuffer
Content:
6. Title: String VS StringBuffer
Content: Difference
7. Title: String VS StringBuffer
Content: Difference between
8. Title: String VS StringBuffer
Content: Difference between String
9. Title: String VS StringBuffer
Content: Difference between String and
10. Title: String VS StringBuffer
Content: Difference between String and StringBuffer
11. Title: String VS StringBuffer
Content: Difference between String and StringBuffer is
12. Title: String VS StringBuffer
Content: Difference between String and StringBuffer is ~~~
String 객체가 담고 있는 문자열은 변경이 불가능 하기에 모든 라인마다 JVM에 새로운 String 객체가 생성됩니다.
StringBuffer 객체는 문자열 버퍼가 존재하고 있어서 하나의 객체에서 작업이 이루어지므로 JVM 메모리를 보다 효율적으로 사용할 수 있습니다.
위와 같은 경우보다 훨씬 더 많은 작업을 요구한다면 StringBuffer를 사용하는게 성능면에서 상당히 유리할 것입니다.
위의 코드를 StringBuffer로 변환하면서 여기서 설명을 마치겠습니다.1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16public String getDescription()
{
StringBuffer description = new StringBuffer("Title: ");
description.append("String ");
.append("VS ");
.append("StringBuffer\n");
.append("Content: ");
.append("Difference ");
.append("between ");
.append("String ");
.append("and ");
.append("StringBuffer ");
.append("is ");
.append("~~~\n");
return description.toString();
}
JVM은 Java Virtual Machine으로 저희가 작성한 .class 자바 코드(애플리케이션)을 동작시켜줍니다.
각 OS에 맞는 JVM이 존재하여 다른 OS 환경에서도 동일하게 자바 코드가 실행되도록 합니다.
JVM이 어떻게 동작하는지 보기 전에 JVM 구조를 먼저 살펴보겠습니다.
크게 Class Loader, Execution Engine, Runtime Data Area로 구성됩니다. 좀 더 자세히 알아보겠습니다.
.class 파일(들)과 CLASSPATH 환경변수로 지정한 jdk/lib에 있는 class 파일들 그리고 .jar 파일까지 모두 JVM 위에 올려놓는 역할을 수행합니다.
바이트 코드를 명령어 단위로 읽어서 실행하는 역할을 합니다. 여기서 바이트 코드는 Class Loader에 올려진 class 파일들이며 애초에 .java → .class(바이트 코드)로 컴파일한 이유는 JVM이 읽을 수 있게 바이트 코드로 변환한 것이고 실행을 위해서는 기계가 읽을 수 있게 변환하는 작업이 필요합니다.
*바이트 코드는 사람에 더 친숙하다고 볼 수 있습니다.(물론 기계어 보단…친숙하실 겁니다. 무려 hex editor로 바이트 코드를 읽을 수 있다구요!)
기계가 읽을 수 있도록 다시 번역을 해야 하는 작업이 여기서 이루어집니다. 두 가지 방식이 존재합니다.
흔히 Python, JavaScript 등이 이 방식으로 실행됩니다. 명령어를 하나씩 읽어 해석하고 실행합니다. (한 번만 실행되는 코드는 보통 이 방식으로 진행됩니다.)
인터프리터 방식으로 실행하다가 적절한 시점에 바이트 코드 전체를 컴파일하여 네이티브 코드로 변경하고 이후에는 인터프리팅하지 않고 네이티브 코드로 직접 실행합니다.
적절한 시점은 이 코드가 자주 실행되는 체크를 하면서 판단하게 됩니다.
또한 네이티브 코드는 캐시에 보관하기에 여러 번 수행되는 코드는 이 방식으로 빠르게 실행시킬 수 있습니다.
JVM이 OS위에서 실행되면서 할당받는 메모리 영역입니다.
PC register / JVM Stack / Native Method / Heap / Method
모든 Thread가 공유하는 영역은 (JVM이 시작될 때 생성되는) Heap과 Method 영역입니다. 그외는 각자 자신만의 영역을 가지고 있습니다. (독립적으로 수행되는 thread를 생각하면 이해가 되실겁니다.)
현재 수행 중인 JVM 명령 주소가 담겨있습니다.
Stack Frame이라는 구조체를 저장하는 스텍입니다.
Stack Frame은 메서드가 수행될 때마다 생성되고 종료될 때 제거됩니다. 그 안에는 local variable array, operand stack, reference of runtime constant pool이 담겨있습니다.
Local variable array는 0번째 인덱스에 메서드를 호출한 클래스(this)가 담겨있고 그 이후로는 메서드 파라미터, 지역변수가 담겨있습니다.
Operand stack은 메서드의 호출 결과를 push, pop하면서 실제 작업을 수행합니다.
Reference of runtime constant pool은 현재 실행 중인 메서드가 속한 클래스의 런타임 상수 풀에 대한 참조가 담겨있습니다.
객체나 인스턴스가 생성되어 저장되는 공간으로 GC의 대상이 되기에 성능 튜닝은 보통 이곳에서 이루어집니다.
JVM이 읽어들인 각각의 클래스와 인터페이스에 대한 런타임 상수 풀, 필드, 메서드의 정보와 static 변수, 메서드의 바이트 코드 등 중요한 정보를 보관하는 영역입니다.
이 중 Runtime Constant Pool 영역이 내부에 따로 존재합니다. 핵심적인 역할을 담당하기 때문입니다. 이곳에서 각 클래스와 인터페이스의 상수뿐만 아니라 메서드와 필드에 대한 모든 레퍼런스까지 담고 있어 이곳을 통해 메소드나 필드의 주소를 찾고 참조를 합니다.
.java 파일이 javac(자바 컴파일러)를 통해 .class 파일(바이트코드)로 변환되고 이로써 JVM이 읽을 수 있게 됩니다. 이런 class 이외에 필요한 다른 class 들을 Class Loader가 올리면 Execution Engine이 이를 실행시킵니다. Runtime Data Area는 Class Loader와 Execution Engine과 상호작용을 합니다.