Paul log

MSA-Order-API 프로젝트 설정

밍튜 — Tue, 11 Feb 2025 10:29:46 +0900

MSA 강좌 중 예제 Order API 소스코드 실행 설정

1. 로컬 컴퓨터에서 docker-compose로 mysql 설치 (명령어 실행전에 docker desktop 실행)

docker-compose up --build

터미널에서 명령어 입력시 docker-compose 설정대로 pulling한다.

RUN ./gradlew bootJar --no-daemon Error가 발생해서 그대로 터미널에 입력.

./gradlew bootJar --no-daemon

빌드 성공.

2. Docker 터미널에 접속

docker-compose에 입력된대로 터미널에 입력

docker run --name order-api-order-db-1 -e MYSQL_ROOT_PASSWORD=rootpassword -e MYSQL_DATABASE=userdb -p 3307:3306 -d mysql:8.0

docker containers에 실행되는 db 확인

springboot 실행

Table 생성 확인

docker 터미널에서 order 테이블에 데이터 입력

docker exec -it order-api-order-db-1 /bin/bash

# container
bash-5.1# mysql -u root -p
mysql> insert into orders (user_id, product_id, quantity) values (1, 1, 5);

데이터 입력 확인

[Java] Hash 알고리즘과 Hash충돌

밍튜 — Fri, 21 Jun 2024 11:27:45 +0900

간단한 배열에서 값을 찾는 코드를 보자.

Integer[] arr = new Integer[4];
arr[0] = 1;
arr[1] = 2;
arr[2] = 5;
arr[3] = 8;

int searchValue = 8;
for (Integer inputValue : arr) {
	if(inputValue == searchValue) {
    	System.out.println(inputValue);
        }
   	}
}

위 arr 배열에서 searchValue = 8을 찾으려면 foreach 문에서 처럼 배열을 모두 뒤져야 찾을수있다.

따라서 성능은 O(n) 이다.

배열의 장점이라고 할수있는 Index로 데이터를 검색했을때 매우 빠르게 검색할수있다. 즉 Index로 검색시 O(1)의 성능으로 찾을수있다.

만약 데이터를 검색할때도 Index를 활용해서 데이터를 한번에 찾을수있다면????

그럼 데이터의 값과 배열의 Index를 맞추어서 저장하면 데이터를 O(1)로 빠르게 가져올수있지않을까??해서 데이터의 값자체를 배열의 Index로 사용해보자

Integer[] arr = new Integer[10];
arr[1] = 1;
arr[2] = 2;
arr[5] = 5;
arr[8] = 8;

int searchValue = 8;
Integer result = arr[searchValue];
System.out.println("result = " + result);

//[null, 1 , 2, null, null, 5 , null, null, 8, null]

배열인덱스 = 데이터값

index 1 = data 1
index 2 = data 2
index 5 = data 5
index 8 = data 8

이렇게 되면 데이터 1을 찾고싶다면 arr[1] , 데이터 8을 검색하고싶다면?? arr[8]을 입력하면되니까 O(1)의 성능으로 매우빠르게 찾을수있다!

그치만... 배열길이가 10인데 배열에 데이터가 들어있는걸 보면 [null, 1 , 2, null, null, 5 , null, null, 8, null] 이네..

그럼 데이터 1, 2 ,5 , 8, 14, 99 를 넣으려면 최소 new Integer[100] 만큼의 배열이 필요하다.

이렇게 인덱스=데이터값으로 만든 배열의 문제는 입력값의 범위만큼 큰 배열을 사용해야해서 배열에 낭비되는 공간이 많이 발생한다.

여기서 해시알고리즘 비슷한걸 을 도입해본다면....

일단 배열의 크기를 100 에서 CAPACITY크기인 10으로 줄여보고, hashIndex를 구하는 함수를 value % CAPACITY(10)으로 정의해보자.

searchValue = 14를 위 배열에서 찾는다고 할때

searchValue를 해시인덱스화 시키면 '4' 가 나오고

arr[해시인덱스=4] = 14로 O(1)의 속도로 빠르게 찾을수있다.

해시(Hash) 알고리즘은 데이터를 찾는 검색 성능을 평균 O(1)로 데이터를 빠르게 찾을수있다.

hashcode를 만드는 실제 계산방법은 다음과같은데

hashCode= s[0] × 31(n−1) + s[1] × 31(n−2) + … + s[n−1]

여기서

s[i] 는 문자열의 i번째 문자
n은 문자열의 길이
31은 해시코드를 계산할때 사용하는 상수

인데..

이 계산하는건 어차피 컴퓨터가 해주는거니까 자세히 알필요는 딱히 없을거같다.

중요한건 해시알고리즘으로 1) 데이터를 해시인덱스화 시킨다 2) 배열의 인덱스=해시인덱스 공간에 데이터를 넣는다

3) 데이터를 찾을때 데이터를 해시인덱스화 시킨 값으로 배열[해시인덱스] 로 조회하면 O(1)로 빠르게 조회할수있다.

만 알면된다.

이 해시알고리즘에는 한계가 있다. 바로 '다른값을 입력했을 때 같은 해시코드가 나올수 있음' 이다.

간단히 말해서

해시알고리즘 비슷한걸 로 해시인덱스값을 구하는 방법이 10으로 나눈 나머지라고 할때

99 % 10 = 9 (해시값)

9 % 9 = 9 (해시값)

으로 99와 9가 모두 해시값이 9로 같다.

이는 저장할 위치가 충돌할수 있다는 한계가있는데 이를 Hash충돌 이라고 한다.

해시 충돌 ㅠㅠ

이 해시충돌 문제를 해결하는 방법은 CAPACITY를 100으로 늘리면 해결되기는 하는데....

이건 메모리 낭비가 심하다는 맨 처음 한계를 해결할수가 없다.

해시 충돌 해결

해시 충돌은 낮은 확률로 일어날수있다고 가정하고 인정하는것이 바로 해결방법이다.

해시 충돌이 난 경우 내부의 데이터를 하나씩 비교해보면 원하는 결과를 찾을수 있다.

즉, 최악의 경우 [9, 19 , 29 , 99 ]를 해시인덱스화 시키면

그림 처럼 9 , 9 , 9 , 9로 같은 해시인덱스가 나오고

arr[9=해시인덱스]에 공간에 9, 19, 29, 99가 다들어간다...

그럼 데이터를 찾을때 arr[9]에 있는 값을 다 뒤져봐야되는 O(n)이 되버린다.

그치만 hashcode를 만드는 실제 방법을 쓰면 거의 충돌이 일어나지 않게 계산이되고

충돌이 되더라도 배열을 쬐끔만 돌면 되기때문에 속도가 거의 O(1)이라고 할수있게되서 다들 Hash를 쓴다고한다...!

[javascript] Javascript에서 자주나오는 'this'란 뭘까

밍튜 — Fri, 26 Apr 2024 12:49:56 +0900

Javascript 'this'

this의 값은 함수를 호출하는 방법에 의해 결정된다.
클로저는 선언되는 위치에 의해 달라진다.

this는 누가 호출했느냐가 this가 된다.
즉 "호출한객체가 this이다."

예제를 보면

const a = {
	name : 'code',
	who : function(){
		console.log(this);
  	}
}

a.who(); 를 호출하면

who function안의 console.log(this)가 실행되고
여기서의 this는 a가 who()를 호출한것이 되므로
const a 객체 본인이된다.

그럼 코드를 변형시켜서

let b = a.who; 즉 a객체의 who함수를 변수 b에 할당하고

b를 실행해보자

b();

그럼 b()는 a.who이고 a.who() 가 실행되면 console.log(this)가 실행되는거고
여기서의 this는 b()를 호출한 'window' 가 된다

bind를 사용해서 this를 예외적으로 고정시켜보자

let bindedC = b.bind(a);

이렇게되면 b의 this는 무조건 a가된다.

bindedC()를 호출하면 ?? b()가실행되고 b()내부의 a.who가 실행되고 최종적으로 a.who의 console.log(this)가 실행되는데
여기서의 this는 b.bind(a)를 했으므로 무조건 a가된다.

즉 console.log의 결과로 a객체가 나온다.

전역컨텍스트에서 this는 window 객체이다.

'use strict'는 엄격모드이다.

객체 메서드에서 this는 함수를 호출한 객체인 Object본인이다.
this가 객체 밖에서 정의되었던 안에서 정의되었던
this가 호출된 그 시점의 객체가 this가 된다.

.바로 왼쪽의 객체가 this

예를들어

fucntion main() {
	console.log(this);
}

const object = {
	name : '나',
	smallObject : {
		name : '너',
		main
	},
};

이렇게 선언되어있을때

object.smallObject.main()을 호출하면??

main()내부 console.log(this)가 실행되고 .main() 왼쪽의 smallObject가 this가된다.

이벤트 처리기 에서의 this는 event.target이다.

[Java] 다형성에 대해 알아보자(feat.다형적 참조, 메서드 오버라이딩)

밍튜 — Thu, 22 Feb 2024 11:06:21 +0900

객체지향 프로그래밍의 대표적 특징들은 다들 알고있을것이다.

추상화, 캡슐화, 상속, 다형성...

그중에 가장 중요하고 이해하기 어렵다는 다형성에대해 알아보자.

다형성은 Polymorphism이라는 이름 그대로 '다양한 형태', '여러 형태'를 말한다.

프로그래밍에서 다형성은 한 객체가 여러 타입의 객체로 취급될수 있는 능력을 말한다.

즉 타입이 결정되어있는 하나의 객체가 다른 타입으로 사용 될수 있다는 뜻이다...

아직 무슨말인지 정확히 모르겠으니 자세히 알아보자

다형성을 이해하기 위해선 2가지 핵심 이론을 알아야 한다.

1. 다형성 참조

2. 메서드 오버라이딩

다형성 참조란 간단히 말해서 "부모는 자식을 담을수 있지만 자식은 부모를 담을수 없다" 라고 할수있다.

다음 그림을 보자

Parent를 상속하는 Child 클래스가 있다고 해보자.

Child 타입의 인스턴스를 생성하면 오른쪽 그림처럼 메모리에 Child와 상속받는 Parent가 모두 생성된다.

위 그림은 Child child1 = new Child();로 선언했을때 그림이다.

다음 그림은 Parent 타입의 클래스를 인스턴스화 했을때 메모리 그림이다.

다형성을 이용해 new Child() 인스턴스를 Parent타입의 poly 변수가 참조하고 있는 그림이다.

여기까지 다형성을 설명해보면

부모 타입의 변수가 자식 인스턴스를 참조한다
부모타입은 자식을 담을수 있다.
Parent poly는 부모타입이고 new Child()를 통해 생성된 결과는 Child 타입이므로
- Parent poly = new Child()는 가능하다
- Child child1 = new parent() 는 불가능! 컴파일 오류 발생함

하지만 다형적 참조에는 한계가 있다.

위 그림에서는 Child인스턴스를 Parent 타입의 poly변수가 참조하고있다.(다형적 참조)

poly는 Parent타입 변수이므로 자식타입의 Child의 childMethod는 호출이 불가능 하다.

그럼이때 '다운 캐스팅'을 해버린다면?

Child child = (Child) poly
child.childMethod()

로 자식타입의 childMethod를 호출하는게 가능하다.

업캐스팅(upcasting): 부모 타입으로 변경
다운캐스팅(downcasting): 자식 타입으로 변경

실행 순서

Child child = (Child) poly //다운캐스팅을 통해 부모타입을 자식 타입으로 변환한 다음에 대입 시도 
Child child = (Child) x001 //참조값을 읽은 다음 자식 타입으로 지정 
Child child = x001 //최종 결과

참고로 캐스팅을 한다고 해서 Parent poly 의 타입이 변하는 것은 아니고 해당 참조값을 꺼내고 꺼낸 참조값이 Child 타입이 된다. 따라서 poly 의 타입은 Parent 로 기존과 같이 유지된다.

메서드 오버라이딩이란 다 아는것처럼 상속받은 메서드를 재정의해서 기존 기능을 덮어 새로운 기능으로 한다는 뜻이다.

다음 코드를 보자

public class OverridingMain {
 	public static void main(String[] args) {
 
 	//자식 변수가 자식 인스턴스 참조
 	Child child = new Child();
 	System.out.println("Child -> Child");
 	System.out.println("value = " + child.value);
 	child.method();
 	
   	 //부모 변수가 부모 인스턴스 참조
 	Parent parent = new Parent();
 	System.out.println("Parent -> Parent");
 	System.out.println("value = " + parent.value);
 	parent.method();
 
 	//부모 변수가 자식 인스턴스 참조(다형적 참조)
 	Parent poly = new Child();
 	System.out.println("Parent -> Child");
 	System.out.println("value = " + poly.value); //변수는 오버라이딩X
 	poly.method(); //메서드 오버라이딩!
  }
}

그림을 통해서 코드를 분석해보면

Parent -> Parent

이 부분이 중요하다!

poly 변수는 Parent 타입이다. 따라서 poly.value, poly.method() 를 호출하면 인스턴스의 Parent 타입에서 기능을 찾아서 실행한다.

'오버라이딩 된 메서드는 항상 우선권을 가진다' <- 이 부분이 핵심!

따라서 Parent.method() 가 아니라 Child.method() 가 실행된다.

[JPA] 영속성 컨텍스트가 뭐야? Entity Manager는 뭐

밍튜 — Thu, 11 Jan 2024 16:05:14 +0900

<영속성 컨텍스트>

JPA에서 가장 중요한 2가지
1. 객체와 관계형 데이터베이스 매핑하기(Object Relational Mapping)
2. 영속성 컨텍스트

EntityManagerFactory -> 고객요청시 EM 생성 -> EM은 내부적으로 DB connection을 사용해서 DB 자원에 접근하고 사용\

그럼 영속성 컨텍스트라는게 대체 뭔가?
한마디로 정의하면 "엔티티를 영구 저장하는 환경"이라는 뜻

-> EntityManager.persist(entity);

여기서 persist() 는 entity를 db에 저장하는게 아니다.
영속성 컨텍스트를 통해서 엔티티를 영속화 한다는뜻이다. 쉽게말해 엔티티를 영속성 컨텍스트라는곳에 저장하는것이다.

영속성 컨텍스트가 그래서 뭔데...
사실 영속성 컨텍스트는 논리적인 개념이다. 그래서 눈에 보이지않는다.
엔티티 매니저를 생성하면 안에 영속성 컨텍스트라는 눈에보이지 않는 공간이 생긴다.

<엔티티의 생명주기>
1. 비영속(new)
2. 영속(managed) .persist()
3. 준영속(detached)
4. 삭제(removed)

비영속상태는 말그대로 객체를 new 해서 생성한상태이고 entitymanager에는 영속되지 않은 상태이다. jpa와는 전혀 관계없는 상태.
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

//1차 캐시에 저장
em.persist(member);

//1차 캐시에서 조회
Member findMember = em.find(Member.class, "member1");

영속상태는 EM안에 있는 영속성 컨텍스트에 new한 객체가 들어가면서 영속된 상태를 말한다.

detached는 말그대로 엔티티를 영속성 컨텍스트에서 분리시키는것을 말하고 객체를 삭제하는게 remove이다.

그럼 영속성 컨텍스트의 이점은??

1. 1차 캐시
: 영속성 컨텍스트는 내부에 1차캐시를 들고있음. 그래서 객체를 생성하고 영속하면 1차캐시 내부에 @Id / Entity로 맵핑되어 들어감.
그럼 id로 조회시 바로 DB를 조회하는게 아니라 1차캐시를 뒤져서 id에 맞는 Entity를 찾아 바로 조회한다.
만약 1차캐시에 없는 id를 조회하면 먼저 1차캐시를 조회후 DB를 조회한다. 그다음 1차캐시에 저장후 반환한다.

2. 동일성(identity)보장
:조회한 entity 객체를 ==비교시 주소가 같음

3. 트랜잭션을 지원하는 쓰기 지원
: transaction.begin();
em.persist(memberA);
em.persirst(memberB);
했을때 영속성 컨텍스트의 1차캐시에 memberA, memberB를 쌓아놓고 이떄 Insert쿼리를 만들어 쓰기지연 SQL저장소에 쌓는다.
transaction.commit(); 할때 DB에 SQL을 보낸다.

왜이런 기능을 지원하는거지?

여기서 버퍼링을 쓸수있다. .persist()할때마다 쿼리를 날리게되면 최적화할수있는 여지가 없다.
member1과 member2를 모아서 한꺼번에 보내는 버퍼링!

4. 변경감지(Dirty Checking)
: member의 속성이 member.setName("zzz")로 변경되었다. 그러고 em.persist(member)를 다시 넣지않아도
JPA는 속성의 변경을 감지해서 바뀐 이름으로 업데이트 쿼리를 날려준다.
아니 따로 업데이트 쿼리를 날리는 명령을 하지도 않았는데 어떻게 자동으로 업데이트 쿼리를 날려주는거지?

비밀은 영속 컨텍스트에 있다.
JPA는 커밋하는 시점에 내부에서 Flush가 호출됨.
커밋할때 엔티티와 스냅샷을 비교한다. 스냅샷이 뭐야?
1차 캐시에는 사실 @ID(PK)와 Entity, 그리고 스냅샷이 있다.

영속성 컨텍스트에 들어온 최초의 시점을 스냅샷을 찍어 저장해둔다. 커밋시점에 영속컨텍스트가 Entity와 스냅샷을 비교해서 달라진게 있다면
UPDATE SQL을 생성해서 쓰기지연SQL저장소에 만들어 넣는다.

위의 그림은 논리적 개념의 영속성 컨텍스트를 그림으로 만든것이다.

1차캐시에 그림과같이 @Id , Entity, 스냅샷이 있어서 엔티티와 스냅샷의 비교가 가능하다.

5. 엔티티 삭제
: Member memberA = em.find(Member.class, "memberA");

em.remove(memberA)하면 커밋시점에 Delete 쿼리가 나가게 된다.

6. 플러시(Flush)
: 영속성 컨텍스트의 변경내용을 DB에 반영하는것을 말한다.
플러시 발생시 변경감지(dirty checking)이 일어남. 1차캐시에 엔티티와 스냅샷 비교후 수정된게 있으면
수정된 엔티티를 쓰기지연 SQL 저장소에 등록한다. 그리고 쓰기지연 SQL저장소의 쿼리를 DB에 전송한다(등록, 수정, 삭제 쿼리)

그럼 영속성 컨텍스트를 플러시하는 방법은 뭐야?

em.flush() 로 직접 호출하거나 트랜잭션 커밋 또는 JPQL 쿼리를 실행하여 플러시를 자동 호출할수있다.

그럼 플러시를 하게되면 EM안에 1차캐시가 다 지워지는건가?
그건 아니다. 플러시는 쓰기지연 SQL저장소에 쌓인 쿼리들이 DB에 반영이 되는 과정이다.

7. 준영속 상태
: 말그대로 영속성 컨텍스트에서 있던 entity가 분리되는것이다. 이렇게되면 영속성 컨텍스트가 제공하는 dirty checking 같은 기능을 사용 못한다.
준영속 상태로 만다는 방법은 em.close() 영속성컨텍스를 종료/ em.detach(member) 특정(member) 엔티티만 초기화 / em.clear() 통째로 날리는
방법이있다.

[Spring] 엔티티 설계시 주의사항

밍튜 — Tue, 2 Jan 2024 16:43:24 +0900

엔티티에는 가급적 Setter를 사용하지 말자

Setter가 모두 열려있다면, 변경 포인트가 너무 많아서 유지보수가 힘들다.

모든 연관관계는 지연로딩으로 설정! (외워야함! 중요!)

즉시로딩(EAGER)은 예측이 어렵고 어떤 SQL이 실행될지 추적하기가 어렵다. 특히 JPQL을 실행할때 N+1문제가 자주 발생한다.
실무에서는 모든 연관관계를 지연로딩(LAZY)로 설정해야 한다.
연관된 엔티티를 함께 DB에서 조회해야 하면 'fetch join'또는 엔티티 그래프 기능을 사용한다.
@XToOne(OneToOne, ManyToOne)관계는 기본이 즉시로딩이므로 직접 지연로딩으로 설정해야한다.

컬렉션은 필드에서 초기화하자

컬렉션은 필드에서 바로 초기화 하는것이 안전하다.

private List<OrderItem> orderItems = new ArrayList<>(); //ex

null 문제에서 안전하다.
하이버네이트는 엔티티를 영속화 할 때, 컬렉션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경한다. 만약 getOrders() 처럼 임의의 메서드에서 컬렉션을 잘못 생성하면 하이버네이트 내부 메커니즘에 문제가 발생할 수 있다. 따라서 필드레벨에서 생성하는것이 가장 안전하고, 코드도 간결하다.

출처 : 인프런 | 김영한 실전! 스프링부트와 JPA활용편

[IntelliJ] 김영한선생님이 알려주신 인텔리제이 유용한 단축키 모음 + 접근제어자 종류

밍튜 — Tue, 12 Dec 2023 14:35:43 +0900

회사에서는 윈도우를 사용하고 있으므로

윈도우 기준으로 작성하겠다.

단어 한칸 블록잡기 : ctrl + w -> 커서가 있는곳에 단어를 블록해준다. 단어 한방에 지우거나 바꿀때 유용
같은단어 전체 블록 : shift + F6
파라미터 정보보기 : ctrl + p
타입 + 변수 자동생성 : ctrl + alt + v
커서가 어디든 ; 붙여서 한줄 내려가기 : ctrl + shift + enter
Generator : alt + insert
Override : ctrl + o
직전에 썼던 클래스 목록보기 : ctrl + e
인라인 베리어블 : ctrl+alt+n
메서드로 뽑아내기(extract method) : ctrl+alt+m ->김영한님이 제일 좋아하는 단축키라고 함
메서드에서 테스트코드 만들기 : ctrl + shift + t

접근제어자 정리도 잘해주셔서 캡쳐해서 정리해보았다.

public : + 같은 프로젝트 전체 다 됨

protected : # 같은 패키지에서 가능 + 상속 관계의 호출 가능
default : ~ (package-private) 같은 패키지에서만 가능

private : - 같은 클래스 안에서만 가능

출처 : 인프런 <김영한의 실전 자바>

[java] static 메서드 사용법(주의점)

밍튜 — Mon, 11 Dec 2023 23:52:37 +0900

static 메서드는 static 만 사용할 수 있다.
- 클래스 내부의 기능을 사용할 때, 정적 메서드는 static 이 붙은 정적 메서드나 정적 변수만 사용할 수 있다.
- 클래스 내부의 기능을 사용할 때, 정적 메서드는 인스턴스 변수나, 인스턴스 메서드를 사용할 수 있다.
반대로 모든 곳에서 static 을 호출할 수 있다.
- 정적 메서드는 공용 기능이다. 따라서 접근 제어자만 허락한다면 클래스를 통해 모든 곳에서 static 을 호출할 수 있다.

무슨 말이냐하면 static 메서드는 static끼리만 사용가능하다.

static메서드에서 새로 만들어진 instance의 변수나 instance의 메서드의 사용은 불가능하다는 말이다.

하지만 static을 붙인 순간 method 메모리의 static영역에 계속 떠있으므로 '접근제어자가 열려있다면!'

어디에서나 누구나 '클래스를 통해서' static 영역의 메서드나 필드에 접근이 가능하다.

클래스 DecoData의 내부를 보면

static 필드 = staticValue

static 메서드 = staticCall()

이 있다.

staticCall()은 같은 static인 staticValue를 참조할 수 있다.

하지만 힙영역의 instanceValue는 참조할수있는 참조값이 없으므로 참조가 불가능하다.(물론 외부에서 참조값이 파라미터로 들어온다면 가능은 하다)

힙영역에서 DecoData의 인스턴스는 (클래스). 쩜!!! .으로 static의 메서드와 필드를 불러올수 있다.

[java] java는 항상 변수의 값을 복사해서 대입한다

밍튜 — Thu, 7 Dec 2023 11:03:35 +0900

변수의 값을 복사해서 넣는다는 말이 무슨말일까???

위에서 int num1 = 5라고 먼저 선언했다

다음으로 int num2

바로 num1의 값을 복사해서 num2에 넣었기때문에

num1과 num2의 값은 아무 상관관계가 없다.

따라서 num1은 5, num2는 10을 넣어준 마지막 코드때문에 num2 = 10이 된다

다음 코드를 보면 더 이해하기 쉬워진다

1. changeNumber 호출 전 , num1: 5 이다

2. changeNumber 변경 전, num2는 changeNumber(num1)에서 받은 5값이 인수로 받아서 5가된다

3. changeNumber 변경 후, num2는 위에 코드 num2 = num2 * 2에서 파라미터 num2가 5로 받아서 왔기때문에 num2 =5*2가 되고 따라서 num2 = 10이 들어가서 10이 출력된다.

4. changeNumber 호출 후, num1은 값만 복사해서 갔기때문에 num2와는 아무상관이없어서 원래의 num1값인 5가 출력된다.

4번에서 바로 java의 대원칙인 'java는 항상 변수의 값을 복사해서 대입한다'가 성립된다.

[NAS] Synology Nas에서 http를 https 주소로 바꿔보자

밍튜 — Wed, 6 Dec 2023 13:34:51 +0900

Docker 에 Container로 app server까지 띄우는데 성공!

그런데 계속 uri를 http://ip:port로 접속해야해야했다.

https를 넣는 방법이 없을까 하고 찾아보는 와중에 다른 블로그를 참고하여 https로 바꾸는데 성공!

참고 : https://siane.tistory.com/328

먼저 nas의 DNS -> 제어판 -> 외부 액세스 -> 고급 탭에서 다음과 같이 설정

일반적으로 http가 쓰는 포트인 80과 https 포트인 443을 열어서 설정해준다.

다음으로 제어판 -> 로그인 포털 -> 고급탭에서 '역방향 프록시'로 들어간다

'생성' 버튼을 눌러 http주소를 https로 설정해보자

이름에는 역방향 프록시 주소 이름을 넣고

소스의 프로토콜은 HTTPS

호스트이름은 알아서 만들어준다.

포트는 아까 HTTPS에서 설정했던 '443' 포트 (사용자설정에 따라 다를수있음)

HSTS 활성화 버튼을 체크해준다

대상의 프로토콜은 http주소를 가진 서버 정보를 입력해준다.

프로토콜은 HTTP, 호스트이름은 localhost, 포트는 해당 서버의 포트번호를 입력한다.

이렇게 설정해주면 소스 - 호스트이름에서 만든 https가 딸린 주소로 접속이 가능하다!