그동안 정신없이 이것저것 시도하면서 혼자 공부를 하던 중, 이것만은 글로 기록해 둬야겠다는 생각이 들어서다.

나는 보통 어떤 기술에 대해 궁금한게 생기면, 그 기술을 직접 사용하여 무언가를 구현해보며 익히는 편이다.(일단 부딪히고 보는 타입)

이번에도 Kotlin과 Spring Webflux에 관심이 생겨 직접 부딪혀 보며 개발을 하려는데..

너무 욕심이 과했던 탓일까? 이해하기 힘든 부분들이 많아 이대로는 진행이 안되겠다 싶어, 예외적으로 선 공부후 개발에 착수하기로 마음먹었다.

이 글은 그 기록의 시작점이다.

Reactive?

전통적인(그리고 현재 대부분의) Spring 애플리케이션은 차단식 동기 프로그래밍으로 구현되어 있으며, 그 근본에는 절차지향(명령형) 프로그래밍이 있다.

말그대로 코드 한줄한줄 따라 내려가면서 명령어가 수행되는 구조인것이다.

이러한 절차지향 프로그래밍 기법은 일반적으로 “차단(Blocking)”을 유발하며, 이 차단은 리소스의 낭비를 유발한다.

웹 어플리케이션의 Requests(threads)와 Response를 공장 노동자와 생산되는 물건에 비유해보겠다.

노동자와 결과물

어떤 공장에서는 전화를 통해 물건의 생산 주문을 실시간으로 받고, 주문을 받는 즉시 공장 노동자는 생산 작업에 착수하며,

생산 작업이 완료되면 물건을 주문자에게 보낸다. 여러개의 물건 생산 주문을 받으면 여러명의 노동자가 동시에 생산 작업에 착수한다.

그림으로 보면 다음과 같다.

이를 Spring Web Application에 비유하면, 노동자는 Thread로 볼 수 있고, 도토리는 Response로 볼 수 있다. 아래의 그림과 같이 말이다.

http Request가 오게되면, 서블릿 컨테이너(Tomcat 등)는 Thread Excutor를 통해 각 요청을 Thread로 처리한다. 이 때, 요청마다 별도로 정보를 저장하는 공간은 ThreadLocal이라는 객체를 통해 처리한다.

만약 노동자가 물건 생산 중 물건생산에 필요한 부품이 부족하여, 외부에서 부품을 사와야 하는 상황이 생긴다면? 당연히 노동자는 부품을 구할때까지 만들던 물건을 완성할 수 없고, 아무일도 하지 못할것이다.

보통의 웹 어플리케이션의 경우 JDBC를 이용하여 데이터베이스에서 정보를 얻어와 요청에 대한 처리를 진행하는 경우가 많다. 이 때 JDBC를 통해 DB에 데이터를 요청하게 되면 Thread는 DB가 데이터를 돌려주기 전까지 아무일도 하지 못하고 기다려야 하는데, 이를 Blocking 상태에 있다고 부른다.

Reactive Programing

이처럼 Thread가 Blocking 상태에 빠져 아무것도 하지못하면, 컴퓨팅 자원이 낭비되는 셈이다.(노동자가 쉬는것처럼)

이를 방지할수 있는 방법중 하나가 바로 Reactive Programing이며, 반응형 프로그래밍이라고도 불리는데, Spring에서는 Spring Webflux가 이 Reactive Programing의 개념을 이용하여 개발되었다. (Non-blocking과 Reactive-streams, Project Reactor에 대해서도 더 다루면 좋겠지만.. 여기서 다 다루기엔 양이 너무 많아서 PASS)

위에서 봤던 공장의 상황을 Reactive Programing 방식으로 다시 바꿔보면 아래와 같다.

주문이 들어오면, 각자 다른 역할을 맡은 노동자들이 컨베이어 벨트 위에 서고, 물건은 컨베이어 벨트 위를 지나면서 점점 완성되어 가는것이다.

이렇게 되면 노동자들은 쉬지 않고 자신의 일을 하는데에만 집중할 수 있으며, 여기서는 컨베이어 벨트가 Thread로, 노동자는 Thread가 아닌 Operator로 치환하여 생각할 수 있다. 여기서 Operator는 Spring Webflux에서 제공하는 메소드(함수)들로, 데이터를 가공하기 위해 쓰이는 함수들이다.(ex. flatMap, map 등)

장점

이렇게 Spring Webflux를 이용하여 Reactive하게 시스템을 구성해 놓게 되면, 설령 DB와 같은 외부 IO접근을 통하더라도 Thread(컨베이어벨트)는 멈추지 않고 제 할일을 할 수 있다.(물론 JDBC는 blocking 방식의 Connector이기 때문에, 대신 R2DBC라는 Connector를 사용해야한다.)

결과적으로 상황에 따라서 기존 시스템보다 작은양의 컴퓨팅 자원으로도 비슷하거나 그 이상의 성능을 낼 수 있으며, 이는 거시적으로 볼 때 에너지 절약과도 이어진다. 이러한 점으로 볼 때 개인적인 생각으로는 미래에는 필수적으로 가져가야한 아키텍쳐중 하나가 아닐까 생각한다.

단점

물론 장점만 있는것은 아닌데, 이렇게 선언적으로 프로그래밍을 하게 되면 무엇보다 데이터의 흐름을 직접 추적하기 어렵고, 이는 디버깅이 어려워지는 효과를 낳는다. 게다가 이 선언적 프로그래밍은 명령지향 프로그래밍보다 러닝커브가 높다. 협업이 필수인 개발자의 세계에서는 이 러닝커브가 큰 걸림돌이 될 수 있을것 같다.

마치며

사실 코드적인 부분들이 이해가 안가서 블로깅을 하려고 의도했는데.. 간단히 정리하려던 개념 부분이 생각보다 복잡하게 되었다…이것도 간략화 한거지만 ㅠㅠ

다음화부터는 본격적으로 코드를 곁들여가면서 기록을 시작해봐야겠다.

응..? 근데 왜자꾸 에러가 나지..? 뭐야대체..

하면서 삽질했던 부분을 기록해 둔다.

다음 테스트를 보자

[PostgresqlGeoRepositoryTest.kt]

@SpringBootTest
@Transactional
internal class PostgresqlGeoRepositoryTest @Autowired constructor(
    private val postgresqlGeoRepository: GeoRepository<MemberCurrentPoint, Long>
){

    @Test
    fun noGeoInfo_findAroundPlaces_noResults(){

        var l = -1
        StepVerifier.create(
            Flux.fromIterable(
                getLngLatPoints().map {
                    l++
                    MemberCurrentPoint(l.toLong(),it.first, it.second)
                }
            ).flatMap {
                postgresqlGeoRepository.save(it)
            }.switchMap{
                postgresqlGeoRepository.findAroundOf(
                    MemberCurrentPoint(
                        0,
                        getLngLatPoints()[0].first,
                        getLngLatPoints()[0].second
                    )
                )
            }.map {
                it.memberId
            }
        ).verifyComplete()
    }
}

위 테스트를 실행하면 exception이 발생한다.

java.lang.IllegalStateException: Failed to retrieve PlatformTransactionManager for @Transactional test:...

찾아보니, paluch가 R2DBC의 경우 테스트에서 @Transactional을 통해 테스트 트랜잭션을 관리할 방법이 없음을 언급하고있다.

(https://github.com/spring-projects/spring-framework/issues/24226)

그리고 해당 이슈에서 힌트를 얻어, 불편하지만 매 단위 테스트마다 Transaction Operator를 달아 Rollback을 하는 수밖에 없었다.

Transaction Operator를 쉽게 관리하기 위해 Transaction Helper라는 클래스를 작성했다.

[TransactionHelper.kt]

..

@Component
class TransactionHelper (
    private val tx: TransactionalOperator
){
    fun getTransaction(): TransactionalOperator = tx

    fun <T> withRollback(publisher: Mono<T>) : Mono<T> {
        return tx.execute {
            it.setRollbackOnly()
            publisher
        }.next()
    }

    fun <T> withRollback(publisher: Flux<T>) : Flux<T> {
        return tx.execute {
            it.setRollbackOnly()
            publisher
        }
    }

    fun <T> executeMonoWithRollback(function: () -> Mono<T>) : Mono<T>{
        return tx.execute {
            it.setRollbackOnly()
            function.invoke()
        }.next()
    }

    fun <T> executeFluxWithRollback(function: () -> Flux<T>) : Flux<T>{
        return tx.execute {
            it.setRollbackOnly()
            function.invoke()
        }
    }

}

그런 다음 테스트 Operator들을 롤백구간으로 감싸준다.

    @Test
    fun noGeoInfo_findAroundPlaces_noResults(){

        var l = -1
        StepVerifier.create(
            transactionHelper.executeFluxWithRollback {
                Flux.fromIterable(
                    getLngLatPoints().map {
                        l++
                        MemberCurrentPoint(l.toLong(), it.first, it.second)
                    }
                ).flatMap {
                    postgresqlGeoRepository.save(it)
                }.switchMap {
                    postgresqlGeoRepository.findAroundOf(
                        MemberCurrentPoint(
                            0,
                            getLngLatPoints()[0].first,
                            getLngLatPoints()[0].second
                        )
                    )
                }.map {
                    it.memberId
                }
            }
        ).verifyComplete()
    }
    

이후 테스트를 진행하면 롤백이 잘 되는것을 볼 수 있다.

이유?

테스트가 아닌 Spring Context에서는 @Transactional이 잘 작동하지만, 왜 테스트에서는 사용이 불가능할까?

그 이유는 크게 두가지로 볼 수. 있다.

첫번째로, Reactive Opertator가 작동하는 방식이다.

기존 차단형 프로그래밍 방식에서 트랜잭션의 상태는 ThreadLocal을 이용해 관리되었다. 하지만 Reactive 프로그래밍에서는 비-차단 이며 단일 스레드로 동작해야하기에 ThreadLocal이라는 클래스는 사용할 수가 없다. (엄밀히 말하면 ThreadLocal의 존재 이유가 없다.)

이 문제를 해결하기 위해 R2DBC에서는 Context라는 객체를 이용하여 각 Flow에 대한 상태를 관리하는데,

문제는 현재 JUNIT에서 이러한 Context에 대한 지원이 완벽하지 않다는것이다.

두번째로, Assertion이다. Test Framework에서 트랜잭션 상태는 Assertion과 강한 커플링을 가진다. (Assertion 성공여부에 따라 트랜잭션이 롤백되거나 되지 않을수 있음을 생각해보면..) 하지만 이 Assertion은 차단을 유발하며, Reactive Flow중간에 이러한 차단 코드를 삽입할 수 없기 때문에, StepVerifier를 이용하여 테스트를 진행해야만 한다. 고로, 트랜잭션 상태를 관리할 수 없다.

..끝

(내가 잘못알고있다면 댓글 주세요..)

Spring Webflux로 만든 애플리케이션을 Production에 배포하기 전엔, 의도치 않은 Blocking Call이 있는지 확인해야한다.

Webflux는 Non-Blocking을 기반으로 동작하기 때문에, 소량의 스레드로 모든 요청을 처리한다. (코어당 하나의 스레드라고 함.)

이 때문에 어느 한 곳 이라도 차단 호출이 존재한다면, 안그래도 적은 수의 가용스레드가 더 적어지게 되고,

나아가 적은 수의 스레드만 사용하는 차단-프레임워크(Spring MVC web같은)처럼 동작하게 된다.

Spring MVC가 보통 약 천개의 스레드로 동작하는 것에 비해, 차단 호출 웹플럭스는 기껏해야 1~8개 정도의 스레드만 사용하므로,

성능차이는 어림잡아 백배 이상 날 것이라 추측 해 볼수 있다.

비 차단 프레임 워크에서 차단 호출을 막는것은 이렇게나 중요한데, 이 차단 호출을 감지하는데에 도움을 주는것이 바로 BlockHound이다.

BlockHound

필자는 BlockHound를 그냥 붙이기만 하면 알아서 차단 호출을 감지해 Error를 발생시켜 줄테니, 그 BlockingError만 확인하고 고쳐주면 될 것이라고 쉽게 생각했다.

그리고 보기좋게 다시 삽질을 또 하게 되었다. 이 글은 삽질을 기억하기 위한 몸부림이다.(공병 아니랄까봐..)

BlockHound 설정

Gradle에 BlockHound 의존성을 추가한다.

...
dependencies {
    implementation 'io.projectreactor.tools:blockhound:1.0.6.RELEASE'
  ...
  }

main메소드에 BlockHound.install() 을 작성한다. 참고로 BlockHound는 실행중 바이트코드 수정이 가능하게 설정된 자바 에이전트이기에, Application을 띄운 다음에 install()을 호출해도 상관 없다.

public static void main(String[] args) {
    SpringApplication.run(MyApplication.class, args);
    BlockHound.install();
}

차단 호출 확인하기&처리하기

이제 어디서 차단-호출이 일어나는지 확인할 일만 남았는데, 막상 Application 이곳저곳을 실행해보면 오만상 BlockingOperationError가 발생한다.

reactor.blockhound.BlockingOperationError: Blocking call! java.io.RandomAccessFile#readBytes
	at java.base/java.io.RandomAccessFile.readBytes(RandomAccessFile.java) ~[na:na]
	...

저 java.io.RandomAccessFile#readBytes 는 BlockHound로 점검을 시작하면 가장 친해질 녀석인데, 처음에 이녀석이 나오면 당황스럽다. 내가 호출한게 아닌데 왜 나오는거지? 하며 말이다.

사실 완전한 Non-Blocking은 존재하기 어렵다. Call stack을 타고타고 깊이 가면 항상 끝에는 read()나 unsafe같은 같은 차단 호출과 관련된 녀석들이 기다리고 있다.

정말 중요한건 차단을 피하는게 아니라, 차단으로 인해 CPU 사이클이 낭비되지 않도록 하는것이다. (https://blog.frankel.ch/blockhound-how-it-works/)

이 때문에 Non-Blocking을 지원하는 많은 Spring Modules가 BlockHound Integration에 자신들의 차단 호출이 어느 정도까지 허용될지 통합해 놓는다.

미처 통합되지 못한 차단 호출은, 직접 BlockHound.install(BlockHoundIntegration) 을 통해 허용할 수 있다.

BlockHound.install(b -> b.allowBlockingCallsInside(InflaterInputStream.class.getName(), "read") // OpenApi Blocking Call 허용
        .allowBlockingCallsInside(OpenAPIService.class.getName(), "build")); // OpenApi Blocking Call 허용

이렇게 하면 직접 차단 호출을 허용할 수 있지만, 너무 남발 했다가는 진짜 막아야 할 차단 호출을 놓칠수도 있으니 주의해서 사용해야 한다.

필자는 이렇게 해서 Jwt를 생성하는 부분과 RandomUUID 생성하는 부분에 차단이 있음을 알아냈고, Mono.create통해 Operation을 비차단 식으로 나누거나 Schedulers를 통해 다른 스레드에서 연산 되도록 수정하였다. 예를 들면,

UUID.randomUUID().toString(); // BlockingOperationError!

Mono.<String>create(sink -> {  // OK
  String uuid = UUID.randomUUID().toString();
  sink.success(uuid);
});

Mono.<String>create(sink -> {  // OK
  String enc = doEncrypt(); // 무거운 암호화 로직
  sink.success(enc);
}).subscribeOn(Schedulers.boundedElastic());

이런식으로 말이다.

완성된 Application.java 코드

@SpringBootApplication
@ConfigurationPropertiesScan
public class MyApiApplication {

    private static final String ARG_ENABLE_BLOCKHOUND = "ENABLE_BLOCKHOUND";

    public static void main(String[] args) {
        Locale.setDefault(Locale.KOREA);
        SpringApplication.run(MyApiApplication.class, args);
        enableBlockHoundIfArgsExists(args);
    }

    public static void enableBlockHoundIfArgsExists(String[] args) {
        if (Objects.isNull(args)) {
            return;
        }
        for (String arg : args) {
            if (Objects.nonNull(arg) && arg.contains(ARG_ENABLE_BLOCKHOUND)) {
                enableBlockHound();
                return;
            }
        }
    }

    public static void enableBlockHound() {
        System.out.println("BlockHound Enabled.");
        BlockHound.install(b -> b.allowBlockingCallsInside(InflaterInputStream.class.getName(), "read")
                .allowBlockingCallsInside(OpenAPIService.class.getName(), "build");
    }
}

끝.

그리고 이 Object 클래스에는 여러가지 기본적인 메소드들이 있는데, 오늘은 그 중 equals 와 hashCode 메소드에 대하여 공부했던 점에 대해 정리해 보고자 한다.

Object 클래스

자바에서 모든 클래스는 Object클래스를 상속하며, 따로 extends 키워드를 사용하여 상속하지 않더라도 컴파일러가 자동으로 Object를 상속하도록 만든다.

이는 모든 클래스가 공통적으로 가져야 하는 메소드들을 지원하기 위함이다.

Object 클래스에는 다음과 같은 11개의 메소드들이 정의되어 있다.

이들 메소드들은 OOP의 효율적인 지원을 위해 꼭 필요한 메소드들이며, 많은 중요한 메소드가 있지만, 오늘은 equals와 hashCode에 대해서 정리해본다.

equals 메소드

equals는 논리적 동치성을 검사하기 위해 존재한다고 볼수 있다. 논리적 동치성이란 그야말로 그 객체가 가지는 값이 같은가를 의미한다.

우리가 잘 알고 있는 java.lang.String 클래스를 예로 들어 보자.

		String str1 = "123";
		String str2 = "456";
		String str3 = new String("123");
		
		System.out.println(str1 == str2); // false
		System.out.println(str1 == str3); // false

위 코드의 출력은 모두 false이다.

이는 == 연산자가 단순히 객체의 메모리 주소를 비교하기 때문이며, 변수가 가리키는 인스턴스가 다르다면 false를 반환한다.

결국 str1과 str3 은 같은 문자열을 가진 것처럼 보이지만, str3이 new 키워드를 통해 새로운 메모리 공간을 할당받아, Heap memory에 인스턴화 되어 존재하게 되었으므로, str1과 str3는 다른 인스턴스가 된다.

우리는 두 String이 똑같은 문자열 값을 가지는지 알고싶다. 그렇다면 어떻게 비교해야 할까?

		String str1 = "123";
		String str2 = "456";
		String str3 = new String("123");
		
		System.out.println(str1.equals(str2)); // false
		System.out.println(str1.equals(str3)); // true

위와 같이 equals 메소드를 이용하여 비교하게 되면, 두 String 객체가 같은 문자열값을 가지는지 비교할 수 있다.

이는 java.lang.String 클래스에서 equals 메소드를 아래와 같이 Override 하고 있기에 가능한 일이다.

    public boolean equals(Object anObject) {
        if (this == anObject) { // 같은 인스턴스인경우 true 리턴
            return true;
        }
        if (anObject instanceof String) { // String 타입의 인스턴스인 경우
            String anotherString = (String)anObject;
            int n = value.length;
            if (n == anotherString.value.length) { // 문자열 값의 길이가 같은 경우, 값 비교 시작
                char v1[] = value;
                char v2[] = anotherString.value;
                int i = 0;
                while (n-- != 0) {
                    if (v1[i] != v2[i])
                        return false; // 중간에 다른 값이 있는 경우 false 리턴
                    i++;
                }
                return true; // 모든 값이 같음, true 리턴
            }
        }
        return false;
    }

이 equals 메소드는 전략적으로 잘 짜여진 equals이다.

이펙티브 자바에서는 효율적인 equals로 재정의하기 위해서는 다음의 순서대로 구현하는것이 좋다고 언급되어 있다.

1. == 연산자를 이용하여 입력이 자기 자신의 참조인지 확인한다.
2. instanceof 연산자로 입력이 올바른 타입인지 확인한다. 이때 null 체크까지 해결되므로, null인지 체크할 필요가 없어진다.
3. 입력을 명시적 형변환 한다.
4. 입력 객체와 자기 자신의 대응되는 논리적 핵심 필드들이 모두 일치하는지 하나하나 검사한다. 이 때, 하나라도 다르다면 false를 리턴하고, 모두 같다면 true를 리턴한다.

이를 위의 String.equals와 비교해보면 완벽히 순서가 일치하는것을 알 수 있다.

추가적으로 덧붙이자면, float 와 double을 제외한 Primitive type은 == 연산자를 이용하여 비교하고, Reference 타입 필드는 각각의 equals 메소드를 이용하여 비교한다.

float와 double을 비교할 때 == 을 사용하지 않는 이유는, float과 double은 부동소수점을 표현하는데에 사용되기도 하기 때문이다.

부동소수점 표현 방식은 오차를 가질 수 있으므로, 정확한 값 비교 연산자인 ==를 사용하는것은 바람직하지 않다.

float와 double을 비교해야만 하는 경우에는 Float.compare 메소드와 Double.compare메소드를 이용하도록 하자.

따라서, equals를 구현할 때에는 논리적인 값을 표현하는 필드에는 어떤 것 이 있는지 생각해보고, 해당되는 필드들에 대하여 위와 같은 순서로 구현하는 것이 좋다.

hashCode 메소드

자바 Object 명세에서는 equals 메소드를 재정의 하였다면 hashCode 메소드 또한 재 정의 하도록 규정하고 있다.

hashCode 메소드는 자바의 Collection 프레임 워크에 존재하는 HashMap과 HashSet등을 지원하기 위하여 만들어 졌으며, 이 메소드는 해당 객체의 hash값을 반환해야한다.

또한, 이 객체와 다른 한 객체의 equals 결과가 true라면, 그 둘의 hashCode 값은 반드시 같아야 한다.

(반대로, hashCode 값이 같다고 해서 equals의 결과가 true일 필요는 없다.)

hashCode의 용도를 간단하게 축약해서 말하자면, “다양한 데이터 타입을 배열에 넣기 위한 인덱스” 정도로 말 할수 있을 것 같다.

다음과 같이, char 타입의 알파벳들을 배열에 저장하는 상황을 떠올려 보자.

만약 ‘E’가 어디에 있는지 찾으려면, 단순 비교 검색으로는 5번의 비교연산이 발생한다.

하지만 hashCode를 이용하여 배열에 저장한다면 더 쉽게 찾을 수 있을 것이다.

위와 같이 각 알파벳의 hashCode를 얻어, 배열의 길이로 나눈 나머지를 인덱스로 정한다면, 각 알파벳이 어디있는지는 hashCode만 계산해내면 알 수 있게 된다.

물론 위의 예는 간략한 예이고, 실제로는 해시 충돌 등 여러 문제를 해결해야 안정적이고 빠른 해시맵(셋)의 성능을 기대할 수 있다.

해시 충돌은 서로 다른 객체에서 동일한 해시코드를 얻는 현상을 일컫으며, 좋은 해시 함수일수록 해시 충돌이 적다.

해시 충돌을 위의 예제에서 찾아보자. 알파벳 ‘E’의 hashCode는 5였다. 하지만 알파벳 ‘M’의 hashCode 또한 5(77 % 8 = 5)이다. 이 둘은 다른 값을 가진 객체지만, 같은 해시코드 값을 가지게 되었다. 이것이 바로 해시 충돌이다.

하지만 안타깝게도 완벽한 hashCode 함수를 만드는것은 불가능에 가깝다. 다만 다행히도 hashCode 함수 또한 효율적으로 동작하도록 작성하는 방법이 있는데, 그것은 다음의 단계를 거친다.

1. int 변수 result를 선언하고, 값 c로 초기화 한다. 이 때 c는 단계 2.1로 계산한 값이다.

2. 해당 객체의 논리적 핵심 필드 f들 각각에 대하여 다음을 수행한다.

   1. 해당 필드의 해시코드 c를 계산한다. 각 필드의 타입에 따라서 아래 사항을 따른다.

      1. Primitive 타입 필드라면, Type.hashCode(f)를 수행한다. int로 예를 들면, Integer.hashCode()이다.

      2. 참조타입 필드면서 이 클래스의 equals 메서드 안에서 이 필드의 equals를 사용한다면, 이 필드의 hashCode메서드 또한 이 단계에서 사용한다. 필드의 값이 null이면 0을 사용한다.

         만약 참조타입 필드면서 이 클래스의 equals 메서드 안에서 이 필드의 equals를 사용하지 않는다면, 해당 필드는 계산에서 제외 해야만 한다.

      3. 필드가 배열이라면, 각각을 별도 필드처럼 다루며, 즉 최상위 1번 단계부터 끝단계 까지를 배열의 원소마다 계산해낸다. 배열의 모든 원소가 논리적 핵심 필드라면 Arrays.hashCode를 사용한다.

   2. 2.1번 단계에서 계산한 해시코드 c를 이용하여 result 변수를 다음과 같이 계산한다.

   result = 31 * result + c;

3. result를 리턴한다.

위와 같은 과정을 통해 이상적인 hashCode 메소드를 구현할 수 있다.

String.hashCode도 위와 비슷한 과정을 따른다.

    public int hashCode() {
        int h = hash; // h를 기본 hash값으로 초기화. 기본 hash변수는 0으로 초기화 되어 있다.
        if (h == 0 && value.length > 0) {
            char val[] = value; // value는 String클래스의 전역변수로, 실제 문자열 값을 char의 배열형태로 가지고 있다.
    
            for (int i = 0; i < value.length; i++) {
                h = 31 * h + val[i]; //각각 char타입 변수에 대해 해시코드를 계산한다.
            }
            hash = h; // 기본 hash변수를 초기화 해준다.
        }
        return h; // h(result)를 리턴한다.
    }

hash의 경우 해시 충돌을 극복하는 방법 등 공부해야 할 게 많지만.. 시간이 된다면 그에 대해서도 좀 더 파서 글을 작성해야겠다.

이상 equals와 hashCode 메소드를 효율적으로 작성하는 방법에 대해 알아 보았다.

이 모든 구현이 귀찮거나 어렵다면, AutoValue 라이브러리로 생성하는것도 좋은 방법이다. AutoValue라이브러리는 위에서 진행한 모든 과정을 자동으로 대신해준다.

AutoValue에 대해서는 다음 기회에…

어렴풋이 회사 인트라넷을 구분하는 단어겠거니, 하고 자세한 개념은 모른채 넘어갔었는데,

문득 하나의 공인 IP로 어떻게 이 많은 컴퓨터들이 인터넷과 연결될까? 하는 궁금증이 생겼고,

그 답이 NAT(NAPT) 에 있다는것을 알게 되었다.

NAT (Network Address Translation)

Basic NAT, 즉 원래의 NAT는 1개의 공인IP 주소에 N개의 사설(가상) IP주소를 매핑하는 주소변환 기술의 이름이다.

현재 IPv4의 주소는 전 세계적으로 고갈 상태에 있는데, NAT는 이 고갈되어가는 주소에 대한 효과적인 해결책 중 하나이며, 회사같은 하나의 공동체에서 보안성을 향상시키기 위한 수단으로 활용될수도 있다.

다음과 같이 여러개의 사설망 IP와, 하나의 공인IP를 할당받은 라우터가 있다고 가정해보자.

(여기에 쓰인 IP주소는 임의의 주소이며, 이해를 돕기위해 사용되었다.)

이러한 상황에서 [사설망 클라이언트 1]이 외부 서버에 IPv4 패킷을 전송하게되면, 라우터는 이 패킷의 출발지 IP를 사설망 IP에서 공인IP주소로 변환한 후, 라우팅 테이블에 맵핑 정보를 기록한다.

이렇게 기록해둔 라우팅 테이블의 정보를 참고하여, 외부 서버(위의 예에서 125.209.222.13)에서 전송되어오는 패킷을 어떤 내부 클라이언트(위의 예에서 10.20.30.1)에게 라우팅 할지 결정하게 된다.

그런데, 만약 둘 이상의 내부 클라이언트가 같은 외부서버에 접근하게 되면 위와 같은 라우팅 테이블로는 어떤 클라이언트에게 패킷을 라우팅 해야 할 지 알 수가 없게 된다.

[응답 패킷을 받아야 하는 클라이언트는 1인가, 3인가?]

이 문제를 해결할 수 있는 대안이 바로 NAPT이다.

NAPT (Network Address Port Translation)

NAPT(또는 PAT)에서는 NAT에 Port Forwarding이 추가된 형태이다.

즉, [내부 클라이언트 IP , 내부 클라이언트 Port , 받을 Port ] 를 저장한다.

아래 그림을 보자.

위와 같이 라우터는 “받을 Port”를 임의로 지정하여 각 내부망 클라이언트에 맵핑 해 줌으로써,

외부에서 하나의 공인 IP로 접근하는 여러 패킷들을 각 클라이언트에게 전달 해줄 수 있다.

이렇게 Port에 따라 다른 목적지로 패킷을 전송하는 것을 Port Forwarding 이라고 하며,

이 Port Forwarding이 NAT와 NAPT의 차이점이기도 하다.

현업에서는 대체적으로 NAPT와 NAT를 구분하지 않고 NAT라고 칭한다.

이상하거나 잘못된 내용에 대한 태클은 달게 받겠습니다!!

방대한 라이브러리로 인해 개발 생산성이 향상된다는 것이 그 이유인데,

C와는 달리 자바는 빌드 후 JVM을 이용하여 직접 실행해주어야 하며, 이로 인해 자바를 모르는 사람들은 자바로 만든 유틸리티를 실행하기 쉽지 않다는,

유틸리티로써는 매우 치명적인 단점이 있다.

그러던 중, 우연히 jar파일을 exe로 변환하는 방법을 알게 되어 독립적인 프로그램을 만들기 위해 삽질을 해보았고,

exe파일에 나의 어플리케이션 코드와 기타 라이브러리를 번들로 컴파일하여 번거로운 실행으로부터 완전히 자유로운 자바 프로그램을 만들게 되어 그 경험을 공유하고자 한다.

준비하기

우선 필자는 eclipse를 이용하여 maven 으로 jar 파일을 빌드 한 다음, Launch4j라는 툴을 이용하여 jar를 exe파일로 변환하는 식으로 진행하였다.

이를 위해 java와 ecelipse환경 세팅이 필요하며, Launch4j는 SorceForge에서 구할 수 있다.

SourceForge에서 Download Latest Version 버튼을 눌러 launch4j 설치 파일(20.09.28 기준 버전 3.12)을 다운받아 실행한 후, 안내에 따라 설치한다.

그 다음 자바로 프로그램을 만들기 위해 프로젝트를 생성한 후, 메이븐 프로젝트로 전환해준다.

이렇게 하면 프로젝트 내에 pom.xml 파일이 생기는데, 이는 maven에서 Dependency를 관리하기 위한 파일로, 이는 여기서 다루기엔 너무 큰 주제이니, 기회가 되면 독립적인 주제로 다뤄보겠다.

pom.xml의 하위에 "maven-assembly-plugin" 이라는 플러그인을 추가해 준다.

  <plugin>  
    <groupId>org.apache.maven.plugins</groupId>  
    <artifactId>maven-assembly-plugin</artifactId>  
    <version>2.2.1</version>  
    <configuration>  
      <descriptorRefs>  
        <descriptorRef>jar-with-dependencies</descriptorRef>  
      </descriptorRefs>  
      <archive>
          <manifest>
              <mainClass> <!--메인 클래스의 path --> </mainClass>
          </manifest>
      </archive>
    </configuration>  
  </plugin>

maven-assembly-plugin은 maven 프로젝트의 결과물을 dependency, module, 기타등등의 파일을 단일 아카이브로 만들게 해주는 플러그인이다.

이를 이용해 우리가 만들 자바 프로젝트를 단일 jar파일로 만들고, 종속 모듈(dependencies)들을 모두 주입하여 하나의 실행파일(Excutable Jar)로 만들어낼것이다.

참고로, maven-assembly-plugin은 jar 뿐만 아니라 다른 형식도 지원한다.

• zip
• tar
• tar.gz (or tgz)
• tar.bz2 (or tbz2)
• tar.snappy
• tar.xz (or txz)
• jar
• dir
• war
• and any other format that the ArchiveManager has been configured for

이외 자세한 사항은 maven document를 참고하자.

메인 클래스는 말그대로 main메소드가 존재하는 클래스를 칭하며, 패키지경로를 포함하여 기입한다.

(프로젝트의 구조가 위와 같고, 메인 메소드가 Application.java에 존재할 때, 메인클래스의 패스는 다음과 같은 형식을 띈다.)

com.convert.prj.Application

Make It!

이제 준비가 끝났다. 이제 원하는 프로그램을 java로 구현하고, 빌드할 차례다.

여기서는 Apache POI를 이용하여 엑셀 파일을 생성하는 예제를 만들어보겠다.

우선 POI를 사용하기 위해 pom.xml에 dependency를 추가해준다.

..

  <dependencies>
	  <!-- https://mvnrepository.com/artifact/org.apache.poi/poi-ooxml -->
	<dependency>
	    <groupId>org.apache.poi</groupId>
	    <artifactId>poi-ooxml</artifactId>
	    <version>4.1.2</version>
	</dependency>
	  <!-- https://mvnrepository.com/artifact/org.apache.poi/poi -->
	<dependency>
	    <groupId>org.apache.poi</groupId>
	    <artifactId>poi</artifactId>
	    <version>4.1.2</version>
	</dependency>
  </dependencies>

..

</project>

Apache POI는 엑셀파일과 관련된 작업을 하기위해 가장 많이 사용되는 라이브러리이다.

이 라이브러리를 통해 엑셀 파일을 생성/수정하거나, 읽어들여 데이터화 할 수 있다.

우선, 엑셀 파일을 만드는 간단한 class를 작성한다.

ExcelMaker.java

package com.convert.prj;

import java.io.FileOutputStream;
import java.io.IOException;

import org.apache.poi.xssf.usermodel.XSSFWorkbook;

public class ExcelMaker {
	

​	/**
	 * 
	 * @return Not Saved to disk XSSFWorkbook Object 
	 * @throws IOException
	 */
	public XSSFWorkbook getExcelFile() throws IOException {
		XSSFWorkbook wb = new XSSFWorkbook();
		// do something...
		return wb;
	}
	
	/**
	 * 
	 * @param wb XSSFWorkbook Object for save
	 * @param path where you save specified path
	 * @return save has successful then true else return false
	 */
	public boolean saveExcelFile(XSSFWorkbook wb, String path) {
		try (FileOutputStream stream = new FileOutputStream(path)) {
			wb.write(stream);
			return true;
		} catch (Throwable e) {
			e.printStackTrace();
			return false;
		}
	}

}

그리고 main에서, standard input으로 엑셀 파일을 생성할 path를 입력받은 후, ExcelMaker를 호출한다.

Application.java

package com.convert.prj;

import java.io.IOException;
import java.util.Scanner;

public class Application {

​	public static void main(String[] args) throws IOException {
​		try(Scanner sc = new Scanner(System.in);){
​			System.out.println("type the path : ");
​			String path = sc.nextLine();
​			ExcelMaker s = new ExcelMaker();
​			s.saveExcelFile(s.getExcelFile(), path);
​		}catch(Exception e) {
​			e.printStackTrace();
​		}
​	}

}

어플리케이션 작성이 완료되면, 아래와 같이 Maven build를 수행해준다.

위와 같이 작성후 Run버튼을 눌러주면, maven이 Project의 target 폴더에 Excutable jar파일을 생성해준다.

이렇게 생성된 Excutable jar 파일은 다른 jar 파일에 비하여 비교적 용량이 큰 것을 볼 수 있는데,

이는 실행에 필요한 라이브러리까지 모두 jar파일 내부에 포함시켰기 때문이다.

이 상태에서 java 명령어를 통해 jar파일을 바로 실행할 수도 있지만,

우리의 목적은 .exe이므로, 아직 가야할 길이 남았다.

우선 launch4j를 실행한다.

output file에는 원하는 결과물의 경로와 파일명.exe를, jar 에는 우리가 방금 빌드한 Excutable jar 파일의 경로를 명시해준다. (각 칸의 옆에있는 폴더 모양 버튼을 통해 입력할 수도 있다.)

그 다음 , Main Class를 명시하는 칸 옆에 폴더모양 버튼을 누르고, 우리가 생성한 Jar를 선택하면, 자동으로 Main Class가 잡힌다.

이제 모든 과정이 끝났다.

launch4j 상단의 톱니바퀴 모양의 버튼을 누르고, 설정파일을 저장하면 자동적으로 해당 경로에 결과물.exe파일이 생성된다. 생성된 실행파일을 실행하면…

매우 잘 실행된다!

이렇게 우리는 라이브러리까지 모두 포함한 독립된 자바 프로그램을 편리하게 실행할 수 있게 되었다.

물론 JRE가 설치되어 있어야 한다는 제약사항이 존재하지만, 자바의 막강한 생산성은 그 단점을 커버 해줄수도 있다.

자바로 웹개발만 해왔다면, 그 웹개발로 쌓은 지식을 이용해 나만의 유틸리티를 만들어보는건 어떨까?