동일하지 않은 어떤 객체 X와 Y가 있을 때, 즉 X.equals(Y)가 '거짓'일 때 X.hashCode() != Y.hashCode()가 같지 않다면, 이때 사용하는 해시 함수는 완전한 해시 함수(perfect hash functions)라고 한다(

: S는 모든 객체의 집합, h는 해시 함수).

Boolean같이 서로 구별되는 객체의 종류가 적거나, Integer, Long, Double 같은 Number 객체는 객체가 나타내려는 값 자체를 해시 값으로 사용할 수 있기 때문에 완전한 해시 함수 대상으로 삼을 수 있다. 하지만 String이나 POJO(plain old java object)에 대하여 완전한 해시 함수를 제작하는 것은 사실상 불가능하다.

적은 연산만으로 빠르게 동작할 수 있는 완전한 해시 함수가 있다고 하더라도, 그것을 HashMap에서 사용할 수 있는 것은 아니다. HashMap은 기본적으로 각 객체의 hashCode() 메서드가 반환하는 값을 사용하는 데, 결과 자료형은 int다. 32비트 정수 자료형으로는 완전한 자료 해시 함수를 만들 수 없다. 논리적으로 생성 가능한 객체의 수가 232보다 많을 수 있기 때문이며, 또한 모든 HashMap 객체에서 O(1)을 보장하기 위해 랜덤 접근이 가능하게 하려면 원소가 232인 배열을 모든 HashMap이 가지고 있어야 하기 때문이다.

예외 처리 과정 프로그래밍에서 예외 처리는 아주 중요하면서도 아주 어렵다.

과하다할 만큼 상세하고 다양하게 예외를 잡아 처리해준다면, 클라이언트도 그렇고 서버도 그렇고 더 안정적인 프로그램이 될 수 있게 도와준다.

예외 처리를 하는 경우와 방법은 다양하다.

메서드 내에서 예외 상황을 예측해서 처리하는 try-catch문을 이용하는 방법 요구사항에 의한 예외 처리 (ex. validation > 특정 값이 0~255범위가 아니면 유효하지 않은 값으로 판단하고 예외 처리) 스프링 시큐리티에서 인터셉터로 잡아서 UnauthorizedException 같은 예외 처리 기타 여러 예외 처리들을 적용하다보면 코드가 엄청나게 복잡해진다.

if문으로 잡든 try-catch로 잡든 상위 메서드로 예외처리를 위임하든 코드는 복잡해진다

그렇게 되면 유지보수하기 아주 어려워진다.

비즈니스 로직에 집중하기 어렵고, 비즈니스 로직과 관련된 코드보다 예외 처리를 위한 코드가 더 많아지는 경우도 생긴다.

이런 문제를 조금이라도 개선하기 위해 @ExceptionHandler와 @ControllerAdvice를 사용한다고 보면 이해가 쉬워진다.

@ExceptionHandler @ExceptionHandler같은 경우는 @Controller, @RestController가 적용된 Bean내에서 발생하는 예외를 잡아서 하나의 메서드에서 처리해주는 기능을 한다.

@RestController public class MyRestController { ... ... @ExceptionHandler(NullPointerException.class) public Object nullex(Exception e) { System.err.println(e.getClass()); return "myService"; } } 위와 같이 적용하기만 하면 된다. @ExceptionHandler라는 어노테이션을 쓰고 인자로 캐치하고 싶은 예외클래스를 등록해주면 끝난다.

→ @ExceptionHandler({ Exception1.class, Exception2.class}) 이런식으로 두 개 이상 등록도 가능하다.

위의 예제에서 처럼하면 MyRestController에 해당하는 Bean에서 NullPointerException이 발생한다면, @ExceptionHandler(NullPointerException.class)가 적용된 메서드가 호출될 것이다.

주의사항/알아 둘 것

Controller, RestController에만 적용가능하다. (@Service같은 빈에서는 안됨.) 리턴 타입은 자유롭게 해도 된다. (Controller내부에 있는 메서드들은 여러 타입의 response를 할 것이다. 해당 타입과 전혀다른 리턴 타입이어도 상관없다.) @ExceptionHandler를 등록한 Controller에만 적용된다. 다른 Controller에서 NullPointerException이 발생하더라도 예외를 처리할 수 없다. 메서드의 파라미터로 Exception을 받아왔는데 이것 또한 자유롭게 받아와도 된다. 예제를 보면서 테스트를 해보도록하자.

@RestController public class MyRestController { @Autowired private MyService myService; @GetMapping("/hello") public String hello() { return "hello";//문자열 반환 } @GetMapping("/myData") public MyData myData() { return new MyData("myName");//object 반환 } @GetMapping("/service") public String serviceCall() { return myService.serviceMethod();//일반적인 service호출 } @GetMapping("/serviceException") public String serviceException() { return myService.serviceExceptionMethod(); //service에서 예외발생 } @GetMapping("/controllerException") public void controllerException() { throw new NullPointerException();//controller에서 예외발생 } @GetMapping("/customException") public String custom() { throw new CustomException();//custom예외 발생 } @ExceptionHandler(NullPointerException.class) public Object nullex(Exception e) { System.err.println(e.getClass()); return "myService"; } } [MyRestController.class]

String타입과 MyData라는 나만의 객체타입을 리턴하는 메서드등의 존재하지만 ExceptionHandler하나로 다 처리할 수 있다.

myService.serviceExceptionMethod는 Service안에서 Exception이 발생하는데 이 메서드를 호출하면 서비스에서 예외가 발생했지만 결국 컨트롤러 내에서 발생한 것과 같으므로 ExceptionHandler가 예외를 잡아내어 "myService"가 리턴된다.

public class CustomException extends RuntimeException{ private static final long serialVersionUID = 1L; } RuntimeException을 확장한 클래스로 CustomException을 만들었다.

이 예외는 NullPointerException이 아니기 때문에 발생하더라도 ExceptionHandler에 의해서 처리되지 않는다.

만약 하나로 더 많은 예외 처리를 하길 원한다면 모든 예외의 부모클래스인 Exception.class를 핸들링하게하면 된다.

@ExceptionHandler(Exception.class) @ControllerAdvice @ExceptionHandler가 하나의 클래스에 대한 것이라면, @ControllerAdvice는 모든 @Controller 즉, 전역에서 발생할 수 있는 예외를 잡아 처리해주는 annotation이다.

@RestControllerAdvice public class MyAdvice { @ExceptionHandler(CustomException.class) public String custom() { return "hello custom"; } } 위와 같이 새로운 클래스파일을 만들어서 annotation을 붙이기만 하면 된다. 그 다음에 @ExceptionHandler로 처리하고 싶은 예외를 잡아 처리하면 된다.

별도의 속성값이 없이 사용하면 모든 패키지 전역에 있는 컨트롤러를 담당하게 된다.

@RestControllerAdvice랑 @ControllerAdvice가 있는데 말 그대로 @RestControllerAdvice는 @RestController에서 발생한 Exception만 캐치하고, @ControllerAdvice는 @Controller에서 발생한 Exception만 캐치한다.

@RestControllerAdvice와 @ControllerAdvice가 존재하는데 @RestControllerAdvice 어노테이션을 들여다보면 아래와 같이 되어있다.

@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @ControllerAdvice @ResponseBody public @interface RestControllerAdvice { //... } 위와 같이 두개의 컨트롤러를 작성했을 때 @RestControllerAdvice를 사용하면 @Controller로 적용한 HelloController에서 발생하는 예외는 @RestControllerAdvice에서 잡아주지 못한다.

@ControllerAdvice와 동일한 역할 즉, 예외를 잡아 핸들링 할 수 있도록 하는 기능을 수행하면서 @ResponseBody를 통해 객체를 리턴할 수도 있다는 얘기다.

ViewResolver를 통해서 예외 처리 페이지로 리다이렉트 시키려면 @ControllerAdvice만 써도 되고, API서버여서 에러 응답으로 객체를 리턴해야한다면 @ResponseBody 어노테이션이 추가된 @RestControllerAdvice를 적용하면 되는 것이다.

@RestController에서 예외가 발생하든 @Controller에서 예외가 발생하든 @ControllerAdvice + @ExceptionHandler 조합으로 다 캐치할 수 있고 @ResponseBody의 필요 여부에 따라 적용하면 된다는 것이다. (제 불찰로 잘못된 정보를 공유했던 점을 수정하였습니다.)

또한, 만약에 전역의 예외를 잡긴하되 패키지 단위로 제한할 수도있다.

@RestControllerAdvice("com.example.demo.login.controller") login모듈에 있는 RestController에서 발생하는 예외를 잡으려면 위와 같이 하면 된다. (패키지 구성을 잘하면 유용하다)

출처: https://jeong-pro.tistory.com/195 [기본기를 쌓는 정아마추어 코딩블로그]

따라서 HashMap을 비롯한 많은 해시 함수를 이용하는 associative array 구현체에서는 메모리를 절약하기 위하여 실제 해시 함수의 표현 정수 범위 N 보다 작은 M개의 원소가 있는 배열만을 사용한다. 따라서 다음과 같이 객체에 대한 해시 코드의 나머지 값을 해시 버킷 인덱스 값으로 사용한다.

// 예제 2 해시를 사용하는 associative array 구현체에서 저장/조회할 해시 버킷을 계산하는 방법
int index = X.hashCode() % M;  

이 코드와 같은 방식을 사용하면, 서로 다른 해시 코드를 가지는 서로 다른 객체가 1/M의 확률로 같은 해시 버킷을 사용하게 된다. 이는 해시 함수가 얼마나 해시 충돌을 회피하도록 잘 구현되었느냐에 상관없이 발생할 수 있는 또 다른 종류의 해시 충돌이다. 이렇게 해시 충돌이 발생하더라도 키-값 쌍 데이터를 잘 저장하고 조회할 수 있게 하는 방식에는 대표적으로 두 가지가 있는데, 하나는 Open Addressing이고, 다른 하나는 Separate Chaining이다. 이 둘 외에도 해시 충돌을 해결하기 위한 다양한 자료 구조가 있지만, 거의 모두 이 둘을 응용한 것이라고 할 수 있다.

Open Addressing은 데이터를 삽입하려는 해시 버킷이 이미 사용 중인 경우 다른 해시 버킷에 해당 데이터를 삽입하는 방식이다. 데이터를 저장/조회할 해시 버킷을 찾을 때에는 Linear Probing, Quadratic Probing 등의 방법을 사용한다.

Separate Chaining에서 각 배열의 인자는 인덱스가 같은 해시 버킷을 연결한 링크드 리스트의 첫 부분(head)이다.

둘 모두 Worst Case O(M)이다. 하지만 Open Addressing은 연속된 공간에 데이터를 저장하기 때문에 Separate Chaining에 비하여 캐시 효율이 높다. 따라서 데이터 개수가 충분히 적다면 Open Addressing이 Separate Chaining보다 더 성능이 좋다. 하지만 배열의 크기가 커질수록(M 값이 커질수록) 캐시 효율이라는 Open Addressing의 장점은 사라진다. 배열의 크기가 커지면, L1, L2 캐시 적중률(hit ratio)이 낮아지기 때문이다.

Java HashMap에서 사용하는 방식은 Separate Channing이다. Open Addressing은 데이터를 삭제할 때 처리가 효율적이기 어려운데, HashMap에서 remove() 메서드는 매우 빈번하게 호출될 수 있기 때문이다. 게다가 HashMap에 저장된 키-값 쌍 개수가 일정 개수 이상으로 많아지면, 일반적으로 Open Addressing은 Separate Chaining보다 느리다. Open Addressing의 경우 해시 버킷을 채운 밀도가 높아질수록 Worst Case 발생 빈도가 더 높아지기 때문이다. 반면 Separate Chaining 방식의 경우 해시 충돌이 잘 발생하지 않도록 '조정'할 수 있다면 Worst Case 또는 Worst Case에 가까운 일이 발생하는 것을 줄일 수 있다(여기에 대해서는 "보조 해시 함수"에서 설명하겠다).

Java 2부터 Java 7까지의 HashMap에서 Separate Chaining 구현 코드는 조금씩 다르지만, 구현 알고리즘 자체는 같았다. 만약 객체의 해시 함수 값이 균등 분포(uniform distribution) 상태라고 할 때, get() 메서드 호출에 대한 기댓값은

이다. 그러나 Java 8에서는 이보다 더 나은

을 보장한다. 데이터의 개수가 많아지면, Separate Chaining에서 링크드 리스트 대신 트리를 사용하기 때문이다.데이터의 개수가 많아지면

과

의 차이는 무시할 수 없다. 게다가 실제 해시 값은 균등 분포가 아닐뿐더러, 설사 균등 분포를 따른다고 하더라도 birthday problem이 설명하듯 일부 해시 버킷 몇 개에 데이터가 집중될 수 있다. 그래서 데이터의 개수가 일정 이상일 때에는 링크드 리스트 대신 트리를 사용하는 것이 성능상 이점이 있다.

링크드 리스트를 사용할 것인가 트리를 사용할 것인가에 대한 기준은 하나의 해시 버킷에 할당된 키-값 쌍의 개수이다. 예제 5에서 보듯 Java 8 HashMap에서는 상수 형태로 기준을 정하고 있다. 즉 하나의 해시 버킷에 8개의 키-값 쌍이 모이면 링크드 리스트를 트리로 변경한다. 만약 해당 버킷에 있는 데이터를 삭제하여 개수가 6개에 이르면 다시 링크드 리스트로 변경한다. 트리는 링크드 리스트보다 메모리 사용량이 많고, 데이터의 개수가 적을 때 트리와 링크드 리스트의 Worst Case 수행 시간 차이 비교는 의미가 없기 때문이다. 8과 6으로 2 이상의 차이를 둔 것은, 만약 차이가 1이라면 어떤 한 키-값 쌍이 반복되어 삽입/삭제되는 경우 불필요하게 트리와 링크드 리스트를 변경하는 일이 반복되어 성능 저하가 발생할 수 있기 때문이다.

Java 8 HashMap에서는 Entry 클래스 대신 Node 클래스를 사용한다. Node 클래스 자체는 사실상 Java 7의 Entry 클래스와 내용이 같지만, 링크드 리스트 대신 트리를 사용할 수 있도록 하위 클래스인 TreeNode가 있다는 것이 Java 7 HashMap과 다르다.

이때 사용하는 트리는 Red-Black Tree인데, Java Collections Framework의 TreeMap과 구현이 거의 같다. 트리 순회 시 사용하는 대소 판단 기준은 해시 함수 값이다. 해시 값을 대소 판단 기준으로 사용하면 Total Ordering에 문제가 생기는데, Java 8 HashMap에서는 이를 tieBreakOrder() 메서드로 해결한다.

해시 버킷의 개수가 적다면 메모리 사용을 아낄 수 있지만 해시 충돌로 인해 성능상 손실이 발생한다. 그래서 HashMap은 키-값 쌍 데이터 개수가 일정 개수 이상이 되면, 해시 버킷의 개수를 두 배로 늘린다. 이렇게 해시 버킷 개수를 늘리면

값도 작아져, 해시 충돌로 인한 성능 손실 문제를 어느 정도 해결할 수 있다.

해시 버킷 개수의 기본값은 16이고, 데이터의 개수가 임계점에 이를 때마다 해시 버킷 개수의 크기를 두 배씩 증가시킨다. 버킷의 최대 개수는 230개다. 그런데 이렇게 버킷 개수가 두 배로 증가할 때마다, 모든 키-값 데이터를 읽어 새로운 Separate Chaining을 구성해야 하는 문제가 있다. HashMap 생성자의 인자로 초기 해시 버킷 개수를 지정할 수 있으므로, 해당 HashMap 객체에 저장될 데이터의 개수가 어느 정도인지 예측 가능한 경우에는 이를 생성자의 인자로 지정하면 불필요하게 Separate Chaining을 재구성하지 않게 할 수 있다.

그런데 이렇게 해시 버킷 크기를 두 배로 확장하는 것에는 결정적인 문제가 있다. 해시 버킷의 개수 M이 2a 형태가 되기 때문에, index = X.hashCode() % M을 계산할 때 X.hashCode()의 하위 a개의 비트만 사용하게 된다는 것이다. 즉 해시 함수가 32비트 영역을 고르게 사용하도록 만들었다 하더라도 해시 값을 2의 승수로 나누면 해시 충돌이 쉽게 발생할 수 있다.

이 때문에 보조 해시 함수가 필요하다.

index = X.hashCode() % M을 계산할 때 사용하는 M 값은 소수일 때 index 값 분포가 가장 균등할 수 있다. 그러나 M 값이 소수가 아니기 때문에 별도의 보조 해시 함수를 이용하여 index 값 분포가 가급적 균등할 수 있도록 해야 한다.

보조 해시 함수(supplement hash function)의 목적은 '키'의 해시 값을 변형하여, 해시 충돌 가능성을 줄이는 것이다. 이 보조 해시 함수는 JDK 1.4에 처음 등장했다. Java 5 ~ Java 7은 같은 방식의 보조 해시 함수를 사용하고, Java 8부터는 다시 새로운 방식의 보조 해시 함수를 사용하고 있다.

final int hash(Object k) {  
        // Java 7부터는 JRE를 실행할 때, 데이터 개수가 일정 이상이면
        // String 객체에 대해서 JVM에서 제공하는 별도의 옵션으로
        // 해시 함수를 사용하도록 할 수 있다.
        // 만약 이 옵션을 사용하지 않으면 hashSeed의 값은 0이다.
        int h = hashSeed;
        if (0 != h && k instanceof String) {
            return sun.misc.Hashing.stringHash32((String) k);
        }
        h ^= k.hashCode();
        // 해시 버킷의 개수가 2a이기 때문에 해시 값의 a비트 값만을 
        // 해시 버킷의 인덱스로 사용한다. 따라서 상위 비트의 값이 
        // 해시 버킷의 인덱스 값을 결정할 때 반영될 수 있도록
        // shift 연산과 XOR 연산을 사용하여, 원래의 해시 값이 a비트 내에서 
        // 최대한 값이 겹치지 않고 구별되게 한다.
        h ^= (h >>> 20) ^ (h >>> 12);
        return h ^ (h >>> 7) ^ (h >>> 4);
    }

그런데 Java 8에서는 Java 7보다 훨씬 더 단순한 형태의 보조 해시 함수를 사용한다.

static final int hash(Object key) {
 int h;
 return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); 
}

Java 8 HashMap 보조 해시 함수는 상위 16비트 값을 XOR 연산하는 매우 단순한 형태의 보조 해시 함수를 사용한다. 이유로는 두 가지가 있는데, 첫 번째는 Java 8에서는 해시 충돌이 많이 발생하면 링크드 리스트 대신 트리를 사용하므로 해시 충돌 시 발생할 수 있는 성능 문제가 완화되었기 때문이다. 두 번째로는 최근의 해시 함수는 균등 분포가 잘 되게 만들어지는 경향이 많아, Java 7까지 사용했던 보조 해시 함수의 효과가 크지 않기 때문이다. 두 번째 이유가 좀 더 결정적인 원인이 되어 Java 8에서는 보조 해시 함수의 구현을 바꾸었다.

String 객체에 대한 해시 함수 수행 시간은 문자열 길이에 비례한다.

때문에 JDK 1.1에서는 String 객체에 대해서 빠르게 해시 함수를 수행하기 위해, 일정 간격의 문자에 대한 해시를 누적한 값을 문자열에 대한 해시 함수로 사용했다.

public int hashCode() {  
    int hash = 0;
     int skip = Math.max(1, length() / 8);
     for (int i = 0; i < length(): i+= skip) 
           hash = s[i] + (37 * hash);
    return hash;
}

예제 10에서 볼 수 있듯이 모든 문자에 대한 해시 함수를 계산하는 게 아니라, 문자열의 길이가 16을 넘으면 최소 하나의 문자를 건너가며(skip) 해시 함수를 계산했다.

그러나 이런 방식은 심각한 문제를 야기했다. 웹상의 URL은 길이가 수십 글자에 이르면서 앞 부분은 동일하게 구성되는 경우가 많다. 이 경우 서로 다른 URL의 해시 값이 같아지는 빈도가 매우 높아질 수 있다는 문제가 있다. (앞부분은 동일하되 뒷부분 문자가 다른경우) 따라서 이런 방식은 곧 폐기되었고, 예제 11에서 보는 방식을 현재의 Java 8까지도 계속 사용하고 있다.

public int hashCode() {  
        int h = hash;
        if (h == 0 && value.length > 0) {
            char val[] = value;

            for (int i = 0; i < value.length; i++) {
                h = 31 * h + val[i];
            }
            hash = h;
        }
        return h;
    }

String 객체 해시 함수에서 31을 사용하는 이유는, 31이 소수이며 또한 어떤 수에 31을 곱하는 것은 빠르게 계산할 수 있기 때문이다. 31N=32N-N인데, 32는 25이니 어떤 수에 대한 32를 곱한 값은 shift 연산으로 쉽게 구현할 수 있다. 따라서 N에 31을 곱한 값은, (N << 5) – N과 같다. 31을 곱하는 연산은 이렇게 최적화된 머신 코드로 생성할 수 있기 때문에, String 클래스에서 해시 값을 계산할 때에는 31을 승수로 사용한다.

멀티쓰레드 프로세스의 경우 여러 쓰레드가 같은 프로세스 내의 자원을 공유해서 작업하기 때문에 서로의 작업에 영향을 주게 된다. (Heap, Method 영역, Runtime Constant Pool 영역은 스레드간 공유 가능한 영역)

만약 Thread1이 작업하던 도중 다른 Thread2에게 제어권이 넘어갔을 때, Thread1이 작업하던 공유데이터를 Thread2가 임의로 변경했다면, 다시 Thread1이 제어권을 넘겨받아 나머지 작업을 마쳤을 때 원래 의도했던 결과와 다르게 결과가 나올 수 있다.

이러한 일을 방지하기 위해 한 쓰레드가 특정 작업을 끝마치기 전까지 다른 쓰레드에 의해 방해받지 않도록 하는 것이 필요하다.

• 임계 영역 : 공유 데이터를 사용하는 코드 영역을 지정
• 락 : 공유 데이터가 가지고 있는 lock을 획득한 단 하나의 쓰레드만 이 영역 내의 코드 수행 가능.

공유 데이터를 사용하는 코드 영역을 임계 영역으로 지정해놓고, 공유 데이터가 가지고 있는 lock을 획득한 쓰레드는 임계 영역 내의 모든 코드를 수행하고 벗어나서 lock을 반납해야만 다른 쓰레드가 반납된 lock을 획득하여 임계영역의 코드를 수행할 수 있게 할 수 있다.

이처럼 한 쓰레드가 진행 중인 작업을 다른 쓰레드가 간섭하지 못하게 막는 것을 동기화라고 한다.

스레드를 동기화하는 방법은 여러가지가 있는데 가장 간단한 방법은 synchronized를 이용해서 임계영역을 설정하는 것이다.

가장 간단한 동기화 방법이며, 이 키워드는 임계 영역을 설정하는데 사용된다. 메서드 전체를 임계 영역으로 설정하거나, 특정 영역을 임계 영역으로 지정할 수 있다.

public synchronized void calcSum() {
	...
}

synchronized(객체의 참조변수) {
	...
}

• 두번째 방법은 메서드 내의 코드 일부를 블럭으로 감싸고 블럭 앞에 synchronized(참조변수) 를 붙이는 것이다. 이때 참조변수는 락을 걸고자 하는 객체를 참조하는 것이어야 한다.
• 이 블럭을 synchronized 블럭이라고 부르며, 이 블럭의 영역 안으로 들어가면서부터 쓰레드는 지정된 객체의 lock을 얻게 되고, 이 블럭을 벗어나면 lock을 반납한다.
• 두 방법 모두 lock의 획득된 반납이 자동적으로 이루어지므로 임계 영역만 설정해주면 된다.
• 모든 객체는 lock을 하나씩 가지고 있으며, 해당 객체의 lock을 가지고 있는 쓰레드만 임계 영역의 코드를 수행할 수 있다.

• 변수의 가시성 문제는 다음과 같다. 변수의 값은 CPU 메모리와 메인 메모리에 저장된다. 이 값을 CPU 메모리인지 메인 메모리에서 가져오는 지 알 수가 없다는 문제가 변수의 가시성 문제이다. 이렇게 CPU 메모리에서 값을 읽어들인다면 매우 안전하지 못한다.

private volatile int counter; public int getNextUniqueIndex() { return counter++; }
출처: https://mygumi.tistory.com/112 [마이구미의 HelloWorld]

• volatile 키워드를 변수 앞에 선언하여 사용할 수 있다. 이로써 가시성 문제를 해결할 수 있다. volatile을 사용하면 counter 변수를 읽고 쓰는 과정은 모든 읽기 쓰기 연산을 메인 메모리에서만 처리된다. 따라서 가시성 문제가 해결된다.
• 경쟁 상태(race condition) - 여러 스레드 같은 시점 변수를 읽는 상태. - 이는 해결이 안됨!
• 즉, volatile의 경우는 하나의 스레드가 쓰기 연산을 하고, 다른 스레드에서는 읽기 연산을 통해 최신 값을 가져올 경우. 즉 다른 스레드에서는 업데이트를 행하지 않을 경우 이용할 수 있다.

AtomicInteger 클래스는 CAS(compare-and-swap) 기반으로 되어있다.

CAS란 특정 메모리 위치의 값이 주어진 값을 비교하여 같으면 새로운 값으로 대체된다.

CAS를 c언어의 코드로 보면 쉽게 이해가 갈 것이다.

Atomic 클래스의 경우는 여러 스레드에서 읽기 쓰기 모두 이용할 수 있다. (CAS)

int compare_and_swap(int* reg, int oldval, int newval)

{
  int old_reg_val = *reg;
  if (old_reg_val == oldval)
     *reg = newval;
  return old_reg_val;
}

출처: https://mygumi.tistory.com/112 [마이구미의 HelloWorld]

1. JAVA Collection Framework

JAVA에서 기본적인 자료구조를 제공하기 위한 환경

JAVA Collection Framework의 상속 기본 구조 2. 각 인터페이스의 특징

인터페이스 구현 클래스 특징 List LinkedList

Stack

Vector

ArrayList

순서가 있는 데이터의 집합, 데이터의 중복을 허용함 Set HashSet

TreeSet

순서를 유지하지 않는 데이터의 집합, 데이터의 중복을 허용하지 않음 Map HashMap

TreeMap

HashTable

Properties

키(key)와 값(value)의 쌍으로 이루어진 데이터의 집합

순서는 유지되지 않고, 키는 중복을 허용하지 않으며 값의 중복을 허용함

3. Collection 인터페이스들의 특징

Collection 인터페이스를 상속받아 List와 Set 인터페이스가 된다. 가. List 인터페이스의 특징

순서가 있는 Collection(여기서 순서는 삽입된 순서를 의미한다.) Data를 중복해서 포함 할 수 있다. (1). LinkedList의 특징

LinkedList만 정의한 내용이 있으니 아래 주소 참고 https://hwan1001.tistory.com/5

[JAVA] 자료구조 클래스 - LinkedList(연결리스트)

1. LinkedList(연결리스트) - LinkedList란 각 노드가 데이터와 포인터를 가지고 한 줄로 연결되어 있는 방식으로 데이터를 저장하는 자료구조이다. - 이름에서 말하듯이 데이터를 담고 있는 노드들이 연결되어 있..

hwan1001.tistory.com (2). Stack의 특징

Data의 삽입과 추출이 후입선출(LIFO) 구조로 되어 있다. push() method : Data 삽입 할 때 사용 pop() method : Data 추출 할 때 사용 peek() method : 추출할 Data를 삭제하디 않고 Data만을 가져올 때 사용 search() method : Stack으로부터 Data를 검색할 때 사용 (3). Vector의 특징

자동으로 동기화를 보장해 준다. ArrayList에 동기화가 보장되도록 최적화한 클래스이다. addElement() method : Data를 삽입할 때 사용 elementAt() method : Data를 추출할 때 사용, Index에 해당하는 객체를 얻어냄 size() method : Vector 내에 존재하는 객체의 수를 얻어낼 대 사용 insertElementAt() method : Vector 내에 중간 삽입할 때 사용 setElementAt() method : Vector 내에 존재하는 Data를 수정할 때 사용 indexOf() method : Vector 내에 Data를 검색할 때 사용, Index를 반환 contains() method : Data의 존재 유무를 알기 위해 사용. (4). ArrayList의 특징

동기화를 보장해주지 않는다. 배열에 동적 메모리 증가 기능을 구현한 클래스이다. 동기화 지원 방법 : List list = Collections.synchronizeList(new ArrayList(…)); add() method : Data 삽입할 때 사용 get() method : Data 추출할 때 사용 toArray() method : ArrayList로부터 배열을 얻어낼 때 사용 contains() method : Data의 존재 유무를 알기 위해 사용 size() method : ArrayList의 요소 개수를 얻어낼 때 사용 나. Set 인터페이스의 특징

집합적인 개념의 Collection 순서의 의미가 없다. Data를 중복해서 포함 할 수 없다. (1). HashSet의 특징

add() method : Data 삽입할 때 사용 next() method : Data 추출할 때 사용(HashSet의 Data 추출은 Iterator을 이용하면 됨) remove() method : Data를 삭제할 때 사용 contains() method : Data의 포함여부를 알기 위해 사용 size() method : HashSet의 요소 개수를 얻어낼 때 사용 4. Map 인터페이스들의 특징

List와 Set이 순서나 집합적인 개념의 인터페이스라면 Map은 검색의 개념이 가미된 인터페이스다. Map인터페이스는 데이터를 삽입할 때 Key와 Value의 형태로 삽입되며, Key를 이용해서 Value를 얻을 수 있다. 가. Hashtable, HashMap의 공통점

내부적으로는 모두 Hash 기법을 이용한다. Map 인터페이스를 구현하고 있다. Key와 Value를 이용해서 Data를 관리한다. 나. Hashtable, HashMap의 차이점

Hashtable은 동기화가 보장된다. HashMap은 동기화가 보장되지 않는다. HashMap의 동기화 지원 방법 : Map m = Collections.synchronizedMap(New HashMap(…)); 다. Hashtable, HashMap과 HashSet과의 관계

HashTable과 HashMap은 둘 다 Map 인터페이스를 구현하고 있다. HashSet은 내부적으로 Hash기법을 사용하지만 Set인터페이스를 구현하고 있다 라. HashMap

객체 생성 : Map<String, Integer> map = new HashMap<String, Integer>(); put() method : Data 삽입할 때 사용 get() method : Data를 추출할 때 사용, argument값은 Key를 사용 마. HashTable

객체 생성 : Hashtable<String, Object> h = new Hashtable<String, Object>(); put() method : Data 삽입할 때 사용 get() method : Data를 추출할 때 사용, argument값은 Key를 사용

5. Sorted 인터페이스들의 특징

Set과 Map 인터페이스를 상속받아 정렬 기능이 추가된 SortedSet과 SortedMap 인터페이스가 된다. 그리고 이들은 각각 TreeSet 클래스와 TreeMap 클래스로 구성된다. TreeSet과 TreeMap은 Set과 Map의 기능을 가지고 있으면서 정렬 기능이 가미되었다는 것이 특징이다. 가. Sorted를 지원하지 않는 클래스

HashSet, HashMap 나. Sorted를 지원하는 클래스

TreeSet, TreeMap 다. TreeMap

Key와 Value로 Data를 관리 Key를 기준으로 오름차순으로 정렬된다. Map 인터페이스를 상속한 SortedMap 인터페이스를 구현한 클래스 라. TreeSet

Set 인터페이스를 상속한 SortedSet 인터페이스를 구현한 클래스 데이터들이 자동으로 오름차순으로 정렬된다. 마. Comparator

TreeSet과 TreeMap은 사용자가 직접 정렬의 방식을 지정할 수 있다. TreeSet과 TreeMap은 정렬을 위한 Comparator 인터페이스를 구현하면 된다. TreeSet에 Data를 집어 넣으면 기본적으로 오름차순(Ascending) 정렬이 되지만 그것도 문자열이나 기본 데이터 타입과 같은 단순한 것에만 해당된다. 이에 사용자가 직접 비교법을 넣어주기 위해 사용하는 것이 Comparator 인터페이스이다.

예시)

SQL 1번으로 100명의 회원을 조회하였는데,

각 회원마다 주문한 상품을 추가로 조회하기 위해 100번의 SQL을 추가로 실행하는 상황을 말한다.

한번 SQL을 실행해서 조회된 결과 수만큼 N번 SQL을 추가로 실행한다고 해서 N+1 문제라 한다.

N+1 문제는 엔티티 글로벌 페치전략에 즉시 로딩을 사용할 때 발생할 수 있다.

JPA를 사용하면서 성능상 가장 조심해야 하는 문제가 바로 N+1 문제이다.

em.find() 메소드로 엔티티를 조회할 때 연관된 엔티티를 로딩하는 전략이 즉시 로딩이면

데이터베이스에 JOIN 쿼리를 사용해서 한 번에 연관된 엔티티까지 조회한다.

Order order = em.find(Order.class, 1L);

// 즉시로딩으로 위 엔티티를 설정하면 실행된 SQL은 다음과 같다.
/*
select o.*, m.*
from Order o
left outer join Member m on o.MEMBER_ID=m.MEMBER_ID
where o.id=1
*/

실행된 SQL을 보면 즉시 로딩으로 설정한 member 엔티티를 JOIN 쿼리로 함께 조회한다.

이 때 문제는 JPQL을 사용할 때 발생한다. 위와 같은 상황에서 JPQL로 조회해보자.

List<Order> orders = em.createQuery("select o from Order o", Order.class).getResultList();
// 연관된 모든 엔티티를 조회한다.

JPA가 JPQL을 분석해서 SQL을 생성할 때는 글로벌 페치 전략을 참고하지 않고 오직 JPQL 자체만 사용한다. 따라서 즉시 로딩 / 지연 로딩을 구분하지 않고 JPQL 쿼리 자체에 충실하게 SQL을 만든다.

1. select o from Order o JPQL을 분석해서 select * from Order SQL을 생성한다.
2. DB에서 결과를 받아 order 엔티티 인스턴스들을 생성한다.
3. Order.member의 글로벌 페치 전략이 즉시 로딩이므로 order를 로딩하는 즉시 연관된 member도 로딩해야 한다.
4. 연관된 member를 영속성 컨텍스트에서 찾는다.
5. 만약 영속성 컨텍스트에 없으면 SELECT * FROM MEMBER WHERE id=? SQL을 조회한 order 엔티티 수만큼 실행한다. ⇒ 만약 조회한 order 엔티티가 10개이면 member를 조회하는 SQL도 10번 실행된다.

이처럼 처음 조회한 데이터 수만큼, 다시 SQL을 사용해서 조회하는 것을 N+1 문제라고 한다.

N+1이 발생하면 SQL이 상당히 많이 호출되므로 조회 성능에 치명적이다.

이러한 N+1 문제는 JPQL 페치 조인으로 해결할 수 있다.

글로벌 페치 전략을 즉시 로딩으로 설정하면 애플리케이션 전체에 영향을 주므로 너무 비효율적이다. 이번에는 JPQL을 호출하는 시점에 함께 로딩할 엔티티를 선택할 수 있는 페치 조인을 알아보자.

즉 JPQL만 페치 조인을 사용하도록 변경해보자.

// 페치 조인 사용 전
JPQL : select 0 from Order o
SQL : select * from Order

// 페치 조인 사용 후
// join 명령어 마지막에 fetch를 넣어주면 된다.
JPQL : 
	select -
	from Order o
	join fetch o.member

SQL:
	select o.*, m.*
	from Order o
	join Member m on o.MEMBER_ID=m.MEMBER_ID

이러한 JPQL 페치 조인은 N+1 문제를 해결하면서 화면에 필요한 엔티티를 미리 로딩하는 형식적인 방법이다.

페치 조인이 현실적인 대안이긴 하지만 무분별하게 사용하면 화면에 맞춘 리포지토리 메소드가 증가할 수 있다. 결국 프레젠테이션 계층(view)이 알게모르게 데이터 접근 계층(repository)을 침범하는 것이다.

각 화면마다 즉시로딩, 지연 로딩의 요구사항이 다르다면 각각 다른 메소드를 정의하고, 각 화면에서 필요한 메서드만 호출하는 방식으로 최적화 할 수 있지만, 뷰와 리포지토리 간에 논리적인 의존관계가 발생한다.

이럴땐 무분별한 최적화로 프레젠테이션 계층과 데이터 접근 계층 간에 의존관계가 급격하게 증가하는 것보다는 적절한 선에서 타협점을 찾는 것이 합리적이다.

강제로 초기화하기는 영속성 컨텍스트가 살아있을 때 프레젠테이션 계층이 필요한 연관 엔티티를 강제로 초기화해서 반환하는 방법이다. (글로벌 페치 전략이 지연 로딩일 때 사용)

class OrderService {
	@Transactional
	public Order findOrder(id) {
		Order order = repository.findOrder(id);
		order.getMember().getName();  // 프록시 객체를 강제로 초기화한다.
		return order;
	}
}

글로벌 페치 전략을 지연 로딩으로 설정하면 연관된 엔티티를 실제 엔티티가 아닌 프록시 객체로 조회한다. 프록시 객체는 실제 사용하는 시점에 초기화된다.

예를 들어, order.getMember() 까지만 호출하면 단순히 프록시 객체만 반환되고 아직 초기화하지 않는다. 프록시 객체는 member.getName() 처럼 실제 값을 사용하는 시점에 초기화된다.

예외 처리 과정 프로그래밍에서 예외 처리는 아주 중요하면서도 아주 어렵다.

과하다할 만큼 상세하고 다양하게 예외를 잡아 처리해준다면, 클라이언트도 그렇고 서버도 그렇고 더 안정적인 프로그램이 될 수 있게 도와준다.

예외 처리를 하는 경우와 방법은 다양하다.

메서드 내에서 예외 상황을 예측해서 처리하는 try-catch문을 이용하는 방법 요구사항에 의한 예외 처리 (ex. validation > 특정 값이 0~255범위가 아니면 유효하지 않은 값으로 판단하고 예외 처리) 스프링 시큐리티에서 인터셉터로 잡아서 UnauthorizedException 같은 예외 처리 기타 여러 예외 처리들을 적용하다보면 코드가 엄청나게 복잡해진다.

if문으로 잡든 try-catch로 잡든 상위 메서드로 예외처리를 위임하든 코드는 복잡해진다

그렇게 되면 유지보수하기 아주 어려워진다.

비즈니스 로직에 집중하기 어렵고, 비즈니스 로직과 관련된 코드보다 예외 처리를 위한 코드가 더 많아지는 경우도 생긴다.

이런 문제를 조금이라도 개선하기 위해 @ExceptionHandler와 @ControllerAdvice를 사용한다고 보면 이해가 쉬워진다.

@ExceptionHandler @ExceptionHandler같은 경우는 @Controller, @RestController가 적용된 Bean내에서 발생하는 예외를 잡아서 하나의 메서드에서 처리해주는 기능을 한다.

@RestController public class MyRestController { ... ... @ExceptionHandler(NullPointerException.class) public Object nullex(Exception e) { System.err.println(e.getClass()); return "myService"; } } 위와 같이 적용하기만 하면 된다. @ExceptionHandler라는 어노테이션을 쓰고 인자로 캐치하고 싶은 예외클래스를 등록해주면 끝난다.

→ @ExceptionHandler({ Exception1.class, Exception2.class}) 이런식으로 두 개 이상 등록도 가능하다.

위의 예제에서 처럼하면 MyRestController에 해당하는 Bean에서 NullPointerException이 발생한다면, @ExceptionHandler(NullPointerException.class)가 적용된 메서드가 호출될 것이다.

주의사항/알아 둘 것

Controller, RestController에만 적용가능하다. (@Service같은 빈에서는 안됨.) 리턴 타입은 자유롭게 해도 된다. (Controller내부에 있는 메서드들은 여러 타입의 response를 할 것이다. 해당 타입과 전혀다른 리턴 타입이어도 상관없다.) @ExceptionHandler를 등록한 Controller에만 적용된다. 다른 Controller에서 NullPointerException이 발생하더라도 예외를 처리할 수 없다. 메서드의 파라미터로 Exception을 받아왔는데 이것 또한 자유롭게 받아와도 된다. 예제를 보면서 테스트를 해보도록하자.

@RestController public class MyRestController { @Autowired private MyService myService; @GetMapping("/hello") public String hello() { return "hello";//문자열 반환 } @GetMapping("/myData") public MyData myData() { return new MyData("myName");//object 반환 } @GetMapping("/service") public String serviceCall() { return myService.serviceMethod();//일반적인 service호출 } @GetMapping("/serviceException") public String serviceException() { return myService.serviceExceptionMethod(); //service에서 예외발생 } @GetMapping("/controllerException") public void controllerException() { throw new NullPointerException();//controller에서 예외발생 } @GetMapping("/customException") public String custom() { throw new CustomException();//custom예외 발생 } @ExceptionHandler(NullPointerException.class) public Object nullex(Exception e) { System.err.println(e.getClass()); return "myService"; } } [MyRestController.class]

String타입과 MyData라는 나만의 객체타입을 리턴하는 메서드등의 존재하지만 ExceptionHandler하나로 다 처리할 수 있다.

myService.serviceExceptionMethod는 Service안에서 Exception이 발생하는데 이 메서드를 호출하면 서비스에서 예외가 발생했지만 결국 컨트롤러 내에서 발생한 것과 같으므로 ExceptionHandler가 예외를 잡아내어 "myService"가 리턴된다.

public class CustomException extends RuntimeException{ private static final long serialVersionUID = 1L; } RuntimeException을 확장한 클래스로 CustomException을 만들었다.

이 예외는 NullPointerException이 아니기 때문에 발생하더라도 ExceptionHandler에 의해서 처리되지 않는다.

만약 하나로 더 많은 예외 처리를 하길 원한다면 모든 예외의 부모클래스인 Exception.class를 핸들링하게하면 된다.

@ExceptionHandler(Exception.class) @ControllerAdvice @ExceptionHandler가 하나의 클래스에 대한 것이라면, @ControllerAdvice는 모든 @Controller 즉, 전역에서 발생할 수 있는 예외를 잡아 처리해주는 annotation이다.

@RestControllerAdvice public class MyAdvice { @ExceptionHandler(CustomException.class) public String custom() { return "hello custom"; } } 위와 같이 새로운 클래스파일을 만들어서 annotation을 붙이기만 하면 된다. 그 다음에 @ExceptionHandler로 처리하고 싶은 예외를 잡아 처리하면 된다.

별도의 속성값이 없이 사용하면 모든 패키지 전역에 있는 컨트롤러를 담당하게 된다.

@RestControllerAdvice랑 @ControllerAdvice가 있는데 말 그대로 @RestControllerAdvice는 @RestController에서 발생한 Exception만 캐치하고, @ControllerAdvice는 @Controller에서 발생한 Exception만 캐치한다.

@RestControllerAdvice와 @ControllerAdvice가 존재하는데 @RestControllerAdvice 어노테이션을 들여다보면 아래와 같이 되어있다.

@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @ControllerAdvice @ResponseBody public @interface RestControllerAdvice { //... } 위와 같이 두개의 컨트롤러를 작성했을 때 @RestControllerAdvice를 사용하면 @Controller로 적용한 HelloController에서 발생하는 예외는 @RestControllerAdvice에서 잡아주지 못한다.

@ControllerAdvice와 동일한 역할 즉, 예외를 잡아 핸들링 할 수 있도록 하는 기능을 수행하면서 @ResponseBody를 통해 객체를 리턴할 수도 있다는 얘기다.

ViewResolver를 통해서 예외 처리 페이지로 리다이렉트 시키려면 @ControllerAdvice만 써도 되고, API서버여서 에러 응답으로 객체를 리턴해야한다면 @ResponseBody 어노테이션이 추가된 @RestControllerAdvice를 적용하면 되는 것이다.

@RestController에서 예외가 발생하든 @Controller에서 예외가 발생하든 @ControllerAdvice + @ExceptionHandler 조합으로 다 캐치할 수 있고 @ResponseBody의 필요 여부에 따라 적용하면 된다는 것이다. (제 불찰로 잘못된 정보를 공유했던 점을 수정하였습니다.)

또한, 만약에 전역의 예외를 잡긴하되 패키지 단위로 제한할 수도있다.

@RestControllerAdvice("com.example.demo.login.controller") login모듈에 있는 RestController에서 발생하는 예외를 잡으려면 위와 같이 하면 된다. (패키지 구성을 잘하면 유용하다)

출처: https://jeong-pro.tistory.com/195 [기본기를 쌓는 정아마추어 코딩블로그]

개인키 = 비밀키 = 비공개키

공개키 기법 = 비대칭키 기법

암호화와 복호화에 사용하는 암호키가 같은지 다른지에 따라 암호화 기법이 대칭키 기법과 비대칭키 기법으로 나뉘어 진다.

1. 대칭키 암호

• 하나의 비밀키를 양쪽(client & server)가 모두 같이 사용

• 암호화와 복호화에 사용하는 키가 같은 암호화 알고리즘

• 공개키와 비밀키를 별도로 가지는 것과 구별되는데, 이와 비교하면 계산속도가 빠르다는 장점

• 비밀키 하나만 알아내면 암호화된 내용을 해독 가능 → 해커로부터 안전 X

• 대킹키 암호는 암호화하는 단위에 따라 스트림암호와 블록암호로 나눌 수 있음

º 스트림암호는 연속적인 비트/바이트를 계속해서 입력받아, 그에 대응하는 암호화 비트/마이트를 생성하는 방식

º 블록암호는 정해진 한 단위(블록)을 입력받아 그에 대응하는 암호화 블록을 생성하는 방식

º 블록암호의 경우 적절한 운용모드를 조합하면 블록 단위보다 큰 입력을 처리할 수 있음. 또한 스트림암호와 유사하게 지속적인 입력에 대해 동작할 수 있음. (대신 입출력 단위는 스트림암호보다 큰 블록 단위가 됨)

• 대킹키 기법을 사용하는 암호 알고리즘 방식으로 DES, 3-DES, AES, SEED, ARIA, MASK 등이 있다.

2. 공개키 암호

• 비밀키 하나 만 가지는 대칭키 암호 방법과 달리, 공개키와 비밀키 두 개가 존재

• 공개키 암호를 구성하는 알고리즘을 대칭키 암호 방식과 비교하여 비대칭 암호라고 불림

• 암호화와 복호화에 사용하는 키가 서로 다름

• 암호화할 때의 키는 공개키(public key), 복호화할 때의 키는 개인키(private key)

• 공개키는 누구나 알 수 있지만, 그에 대응하는 비밀키는 키의 소유자만이 알 수 있어서

  특정한 비밀키를 가지는 사용자만이 내용을 열어볼 수 있도록 하는 방식.

송신자는 수신자의 공개키를 받아 데이터를 암호화하여

네트워크를 통해 원격지에 전달.

수신자는 공개키로 암호화된 데이터를 자신의 개인키로 데이터를 복호화하여 평문을 복원.

• 공개키로 암호화한 메세지는 수신자의 개인키로만 해독할 수 있으므로 안전하게 상대방에게 메세지를 전달해 줄 수 있음.

• 대칭키(비밀키)알고리즘에 비하여 속도가 느리다. (약 1000배)

• 속도가 느리기 때문에 긴문서의 암호화하는 경우보다 대칭키 알고리즘의 키값에 대한 암호에 사용.

• 대표적인 공개키 알고리즘으로 RSA, Elgamal 등이 있음.

공개키 암호화 개념도

※ 비밀키 암호화와 공개키 암호화의 비교

아파치 ( Apache )

Apache 서버는 요청 하나 당 프로세스(또는 쓰레드)가 처리하는 구조입니다.

즉 요청이 많을수록 CPU와 메모리 사용이 증가하기 때문에 성능 저하가 있을 수 있습니다.

또한 Apache 서버의 프로세스가 블록킹( blocking )이 되면 요청을 처리하지 못하고, 처리가 완료 될 때까지 계속 대기하는 일이 발생합니다.

이와 같은 문제들은 Keep Alive를 활성화 함으로써 해결이 가능하지만, Keep Alive 때문에 대량 접속 시 효율이 급격하게 떨어지는 또 다른 문제점이 발생합니다.

이를 이해하기 위해서는 Keep Alive에 대한 개념이 필요하므로 잠시 언급하도록 하겠습니다.

Keep Alive

HTTP 프로토콜의 특성상 한 번 통신이 이루어지면 접속을 끊어 버리지만, KeepAlive On 상태에서는 KeepAliveTimeOut 시간 동안 접속을 끊지 않고 다음 접속을 기다립니다.

즉, 한 번 연결된 클라이언트와 통신을 유지하고 있기 때문에, 다음 통신 시에 Connection을 생성하고 끊는 작업이 필요 없게 됩니다.

따라서 Keep Alive을 활성화 함으로써, 성능 향상을 기대 할 수 있습니다.

정적 자원( html파일, 이미지 파일 등 )으로만 구성된 웹 서버에 KeepAlive On으로 설정할 경우 약 50%의 성능 향상을 보인다고 합니다.

단 이와 같은 성능 향상을 보이려면 서버가 바쁘지 않아야 하는데, 바쁜 서버 환경에서 KeepAlive On으로 설정해 놓을 경우,

모든 요청 마다 연결을 유지해야 하기 때문에 프로세스 수가 기하급수적으로 늘어나 MaxClient값을 초과하게 됩니다.

따라서 메모리를 많이 사용하게 되며 이는 곧 성능 저하의 원인이 됩니다. ( 대량 접속 시 효율이 떨어짐 )

이에 따라 Apache 2.4 버전부터 Keep Alive에 대한 고민을 해결하는 새로운 MPM 방식인, Event MPM 방식을 지원합니다.

이 밖에 Apache 2.4 버전에서는 성능 개선을 최우선 과제로 삼고, 더불어서 캐시, 프록시 모듈, 세션 제어, 비동기 읽기 및 쓰기 지원 기능을 개선 했다고 합니다.

Apache가 성능 향상에 투자를 한 이유는, 최근 웹 서버가 정적 데이터 처리를 통한 속도 향상을 노리는 프록시나 캐싱 처리용 서버로 사용하는 경향이 늘면서 속도에 매우 민감해졌기 때문입니다.

조금 뒤에 살펴 볼 Nginx가 성장하게 된 계기가 바로 Apache보다 성능상의 장점을 갖고 있기 때문이죠.

먼저 Apache 2.4버전에서 어떤 변화가 있었는지 살펴보도록 하겠습니다.

아파치 2.4의 새로운 기능 ( 공식 사이트 - 링크 )

1. ( RUN-TIME ) Loadable MPMS

Apaceh 2.2까지는 Multi-Processing Modules ( MPMS )를 사용하기 위해서 컴파일 설치를 할 때 결정지어야 했습니다.

그러나 Apache 2.4부터는 런타임에서 결정할 수 있도록 Loadable Module 기능을 제공합니다.

Apache 2.4 컴파일 설치할 때 수행하는 Configure에서 –enable-mpms-shared 옵션으로 설정이 가능합니다.

2. Event MPM

Apache 2.2까지는 Event Driven 방식을 지원하지 않았습니다.

Evnet MPM 방식은 Keep Alive에 대한 고민에서 출발한 새로운 MPM 방식입니다.

이 방식은 사용자 요청과 Keep Alive한 Apache의 요청을 그대로 맺어주는 것이 아니라, 요청을 처리하는 쓰레드를 따로 두어 분산된 처리를 하는데 그 목적을 두고 있습니다.

3. Asynchronous Support

비동기 읽고/쓰기에 대한 기능을 지원합니다

(따로 설정하거나 하는 것은 없고 내부 구조적으로 지원한다고 합니다. )

4. NameVirtualHost Deprecated

Apache 2.4 에서는 NameVirtualHost가 앞으로 사용되지 않는 옵션으로 변경되었습니다.

NameVritualHost 디렉티브는 더 이상 어떠한 영향을 주지 않으며, 작성 시 경고 메시지를 출력합니다.

대신 묵시적으로 다루어진다고 하는데, 이는 httpd.conf 파일에서 아래의 코드를 작성하지 않아도 묵시적으로 인식한다는 의미입니다.

NameVirtualHost *:80

5. Config File Variables

Apache 2.4 에서는 설정 파일 내에서 변수를 사용할 수 있게 되었습니다.

Define 키워드로 이용해서 변수를 정의합니다.

ex)

Define servername www.example.com

DocumentRoot /var/www/${servername}/htdoc

엔진엑스 ( Nginx )

Nginx는 보안과 속도를 최적화 시키려는 노력에서 탄생한 웹서버이며, 사용이 매우 심플하고 규모가 작은 서비스이면서 정적 데이터 처리가 많은 서비스에 적합합니다.

Apache 에서 지원하는 수많은 기능이 필요 없고 알려진 보안 문제들은 특별한 업데이트 없이 Nginx 자체에서 처리해주고 있습니다.

Nginx는 프로그램의 흐름이 이벤트에 의해 결정이 되는 Event Driven 방식의 웹 서버입니다.

즉 요청에 대한 각 상태( state )를 정해서, event가 발생할 때마다 event를 처리합니다.

적은 수의 쓰레드로 효율적인 일 처리를 하며, 쓰레드를 적게 사용 하기 때문에 쓰레드당 할당되는 메모리도 적게 사용하는 구조입니다.

또한 쓰레드를 많이 사용하지 않기 때문에 context switching 비용이 적고, 따라서 CPU 소모도 적습니다.

그러나 모듈 개발이 어려우며 다양한 모듈이 없다는 것이 단점입니다.

Apache와 Nginx 비교

Nginx 는 비동기 이벤트 기반으로 요청을 처리하고, Apache 서버는 요청 당 쓰레드 또는 프로세스가 처리하는 구조 입니다.

최근 대용량의 정적 파일 및 큰 규모의 사이트가 많아짐에 따라 대량 접속에도 적은 리소스를 사용하며 빠르게 서비스를 할 수 있는 웹 사이트가 대세가 되었는데, 이런 면에서 Nginx가 각광 받기 시작했습니다.

성능 면에서 Apache 2.2는 Nginx에 뒤쳐졌기 때문에 Nginx가 성장하게 되었습니다.

그러다가 2012년에 빠른 응답 속도와 적은 리소스 사용 부분을 개선한 Apache 2.4를 발표하면서, Nginx에 대응하기 시작 했습니다.

그럼에도 Nginx가 성능 면에서는 Apahce 2.4 보다 좋다고 합니다. ( 엄청 큰 차이는 아닙니다. )

하지만 PHP 모듈 등을 직접 적재할 수 있는 Apache가 구조상 이점이 있기에 복잡한 웹 사이트의 경우 Apache가 적합합니다.

세션 클러스터링 같은 특별한 목적을 추가적으로 수행하는 세팅을 할 경우에는 별도의 과정을 거쳐야 하기 때문에,

이러한 별도의 작업이 많이 필요한 서비스의 경우에도 유지 보수 측면에서 Apache가 유용합니다.

즉 안정성과 확장성, 호환성에서 Apache가 우세, 성능 면에서는 Nginx가 우세하다는 것이 결론입니다.

[ 참고 ]

http://linux.systemv.pe.kr/apache-2-4-new-features/ - 아파치 2.4

https://prezi.com/romcehawisgh/nginx/ - nginx 특징

https://prezi.com/ymg_mme4iq8m/apache-mpm-event/ - 아파치 MPM event 방식 , nginx