병렬 작업 처리가 늘어나게 되면 스레드 개수가 증가되고, 그에 따른 스레드 생성과 스레드 스케줄링으로 인해 CPU의 메모리 처리량이 늘어나게 된다. 이는 애플리케이션 성능의 저하와 직결된다. 이렇게 갑작스레 늘어날 수 있는 병렬 작업 처리량을 관리하기 위해서 스레드풀을 사용한다.

스레드풀은 스레드가 처리해야할 작업량을 조절할 수 있도록 한다. 스레드풀은 작업 큐 (Queue)에 작업을 저장해놓고 병렬로 처리할 수 있는 스레드의 개수를 제한한다. 각 스레드는 큐에서 작업을 얻어와 처리하고, 작업이 끝나면 다음 작업을 다시 큐에서 얻어온다. 결과적으로 작업 요청이 폭증하여도 애플리케이션 기능이 급갑하지 않게 된다.
자바에서는 스레드풀을 생성하고 사용할 수 있도록 java.util.concurrent.ExecutorService 인터페이스와 Executors 클래스를 제공한다. Executors의 정적 메서드를 통해 ExecutorService를 구현할 수 있는데, 이 구현 객체가 스레드풀을 의미한다.

[스레드풀의 작업 방식]

1. 작업 요청이 들어온다.
2. 스레드풀이 작업을 큐에 적재해놓는다.
3. 실행 대기 상태인 스레드가 순서대로 큐를 처리한다.
4. 결과를 리턴한다.

스레드풀 생명주기 관리(생성, 종료)

스레드풀을 생성하기 위해서는 ExecutorService를 구현해야 한다. 기본적으로는 ExecutorService 를 구현하고 있는 ThreadPoolExecutor 클래스를 생성해서 쓰면 되지만, Executor 클래스에서 간편하게 스레드풀을 생성할 수 있는 static 메서드를 제공한다.

• newCachedThreadPool()

• newFixedThreadPool(int nThreads)

    public static ExecutorService newFixedThreadPool(int nThreads) {
            return new ThreadPoolExecutor(nThreads, nThreads,
                                          0L, TimeUnit.MILLISECONDS,
                                          new LinkedBlockingQueue<Runnable>());
        }

  초기 스레드 수는 0개이고, 코어 스레드와 최고 스레드 수는 생성 시 입력한 int 값, 고정된 값으로 스레드풀을 생성하는 메서드이다. idle한 스레드를 따로 처리하지 않고 그냥 둔다.

위처럼 설정되어 있는 스레드풀 이외에 작업자가 원하는 상태의 스레드를 얻고 싶다면 ThreadPoolExecutor 객체를 생성하면 된다.

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize, 
                          long keepAliveTime, 
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue) {
    this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
         Executors.defaultThreadFactory(),defaultHandler);
}

스레드풀 종료

스레드풀은 데몬 스레드가 아니기 때문에 main 스레드가 종료되더라도 계속 실행 상태로 남아있다. 그래서 main() 호출이 종료되어도 애플리케이션 프로세스는 종료되지 않는다. 애플리케이션을 종료하려면 스레드풀을 종료시켜서 스레드들이 종료상태가 되도록 처리해주어야 한다. ExecutorService는 종료와 관련하여 세 개의 메서드를 제공한다.

• **void shutdown()**

  현재 처리 중인 작업 뿐 아니라 작업 큐에 대기하고 있는 모든 작업을 처리한 뒤에 스레드풀을 종료 시킨다.

• **List<Runnable> shutdownNow()**

  현재 작업 처리 중인 스레드를 interrupt 해서 작업 중지를 시도하고 스레드풀을 종료 시킨다. 작업을 완료하지 못한 스레드에 대한 정보가 List로 리턴된다.

• **boolean awaitTermination(long timeout, TimeUnit unit)**

  shutdown() 호출 이후, 모든 작업 처리를 timeout 시간 내 완료하면 true, 완료하지 못하면 작업 처리 중인 스레드를 interrupt하고 false를 리턴한다.

따라서 모든 작업을 마무리하고 스레드풀을 종료할 때에는 shutdown(), 바로 작업을 종료하려면 shutdownNow()을 호출한다.

작업 생성과 처리 요청

작업 생성

작업은 Runnable 또는 Callable 을 구현하는 것으로 표현한다. 두 인터페이스의 차이점은 리턴값의 유무이다. Callable은 파라미터 T 타입을 call()의 리턴값으로 반환한다.

Callable<T> task = new Callable<T>(){

    @Override
    public T call() throws Exception{
        // code
        return T;
    }
}

스레드풀의 스레드는 작업 큐에서 Runnable 또는 Callable 객체를 가져와 run(), call()을 실행한다.

작업 처리 요청

작업 처리 요청이란 ExecutorService의 작업 큐에 생성한 작업 (Runnable or Callable) 객체를 넣는 행위를 말한다. 이 처리를 위해 두 가지 메서드를 제공한다.

• void execute(Runnable command): Runnable을 작업 큐에 저장.

• Future<?> submit(Runnable task)

• Future<V> submit(Runnable task, V result)

• Future<V> submit(Callable<V> task)

  Runnable 또는 Callable을 작업 큐에 저장하며, Future 라는 객체가 리턴되어 작업 결과를 확인 가능하다.

리턴값의 유무와 별개로, 두 메서드의 또 다른 차이점은 execute()의 경우 스레드에서 예외가 발생했을 때 스레드가 종료되고 해당 스레드는 스레드풀에서 제거된다. 따라서 스레드풀은 다른 작업을 처리하기 위해서 새로 스레드를 생성하게 된다. 반면 submit()의 경우 스레드가 남아있기 때문에 스레드를 재사용할 수 있다. 따라서 생성 ovehead를 줄이기 위해 submit()를 사용하는것이 좋다.

다음 예제는 의도적으로 NumberFormatException을 발생시켜서 위 두 메서드의 차이를 확인하는 예제이다.

public class ThreadPoolA {
    public static void main(String[] args) throws InterruptedException {

        ExecutorService executorService = Executors.newFixedThreadPool(2);

        for(int i=0;i<10;i++){

            Runnable runnable = new Runnable() {

                @Override
                public void run() {
                    ThreadPoolExecutor threadPoolExecutor = 
                            (ThreadPoolExecutor) executorService;
                    int poolSize = threadPoolExecutor.getPoolSize();
                    String threadName = Thread.currentThread().getName();
                    System.out.println("총 스레드 개수 :" + poolSize + " / 작업 스레드 이름 : "+ threadName);

                    int value = Integer.parseInt("삼");
                }
            };
            executorService.execute(runnable);
//            executorService.submit(runnable);
            Thread.sleep(1000);
        }
        executorService.shutdown();
    }

}

총 스레드 개수 :1 / 작업 스레드 이름 : pool-1-thread-1
Exception in thread "pool-1-thread-1" java.lang.NumberFormatException: For input string: "삼"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at java.lang.Integer.parseInt(Integer.java:615)
    at org.java.chap12.thread_pool.ThreadPoolA$1.run(ThreadPoolA.java:21)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-3
Exception in thread "pool-1-thread-3" java.lang.NumberFormatException: For input string: "삼"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at java.lang.Integer.parseInt(Integer.java:615)
    at org.java.chap12.thread_pool.ThreadPoolA$1.run(ThreadPoolA.java:21)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-2
Exception in thread "pool-1-thread-2" java.lang.NumberFormatException: For input string: "삼"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at java.lang.Integer.parseInt(Integer.java:615)
    at org.java.chap12.thread_pool.ThreadPoolA$1.run(ThreadPoolA.java:21)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-4
Exception in thread "pool-1-thread-4" java.lang.NumberFormatException: For input string: "삼"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at java.lang.Integer.parseInt(Integer.java:615)
    at org.java.chap12.thread_pool.ThreadPoolA$1.run(ThreadPoolA.java:21)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-5
Exception in thread "pool-1-thread-5" java.lang.NumberFormatException: For input string: "삼"
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at java.lang.Integer.parseInt(Integer.java:615)
    at org.java.chap12.thread_pool.ThreadPoolA$1.run(ThreadPoolA.java:21)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-6

execute()로 스레드풀에 작업을 수행했을 때에는 작업 중 예외가 발생했을 때 스레드를 종료하고 새 스레드를 만든다. 스레드가 1부터 10까지 계속 생성되어서 작업을 처리하고 있는 것을 볼 수 있다.

반면 submit()으로 처리했을 때를 보자.

총 스레드 개수 :1 / 작업 스레드 이름 : pool-1-thread-1
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-2
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-1
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-2
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-1
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-2
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-1
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-2
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-1
총 스레드 개수 :2 / 작업 스레드 이름 : pool-1-thread-2

총 스레드 개수는 두 메서드 모두 2개로 같지만, 작업 스레드 개수가 submit()의 경우 2개인 것을 확인할 수 있다. 스레드가 종료되지 않고 계속해서 다른 작업을 수행하기 때문이다.

블로킹 방식의 작업 완료 통보

ExecutorService.submit() 은 Runnable 또는 Callable의 작업을 작업 큐에 저장하고 Future<V> 를 리턴한다. Future 객체는 하나의 작업 결과가 아닌 최종 결과를 얻는데 사용된다. 즉 하나의 작업 결과를 블로킹(지연)하여 모든 결과를 기다린다는 의미이다. 이 떄문에 Future을 지연 완료 (pending completion) 객체라고도 한다. Furture.get()를 호출하면 스레드가 작업을 완료할 때까지 블로킹되었다가 작업을 완료하면 처리 결과를 리턴한다.

• **V get():** 작업이 완료될 때까지 블로킹되었다가 처리 결과 리턴
• V get(long timeout, TimeUnit unit): timeout 내에 리턴하지 않으면 TimeOutException 발생

리턴 타입인 V는 submit()의 매개변수에 따라 Callable 또는 임이의 타입 파라미터 V이다.

Future을 이용한 블로킹 방식의 작업 완료 통보에서 주의할 점은 작업을 처리하는 스레드가 작업을 완료하기 전까지는 get() 호출이 블로킹(지연) 되므로 다른 코드를 실행할 수가 없다는 점이다. 따라서 새로운 스레드 또는 스레드풀의 또 다른 스레드가 get() 호출을 담당해야 한다.

new Thread(new Runnable(){

    @Override
    public void run(){
        try{
        future.get();
        } catch (Exception e){}
    }

}).start();

executorService.submit(new Runnable(){
    @Override
    public void run(){
        try{
        future.get();
        } catch (Exception e){}
    }
});

Future에는 get() 말고도 작업이 종료되었는지 확인하는 isDone(), 작업 취소 여부를 확인하는 isCancled() 등 추가 메서드가 있다.

리턴값이 없는 작업 완료 통보

작업 완료에 대해서 리턴값이 필요 없다면 submit(Runnable task)를 이용하면 된다. submit()의 매개변수로 리턴값이 있는 Callable이나 Runnable과 더불어 타입 파라미터를 넣어주면 거기에 맞는 타입을 리턴하지만, Runnable만 매개했을 경우 null이 리턴된다.

정상적으로는 null이 리턴되지만, 스레드가 작업 처리 도중 interrupt 되면 InterruptedException을 발생시키고, 예외가 있을 경우 ExecutionException을 발생시킨다.

try{
  executorService.submit(runnable).get();
} catch (InterruptedException e){
  System.out.println("interrupted"); // interrupted 되었을 때 코드
}   catch (ExecutionException e){
  System.out.println("error occurred"); // 예외 발생 시 코드
  e.printStackTrace();
}

아래 예시를 보자.

package org.java.chap12.thread_pool;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class ThreadPoolB {

    public static void main(String[] args) {

        ExecutorService executorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());

        System.out.println("task is being processed");

        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                int sum = 0;
                for(int i = 1;i<=10;i++){
                    sum +=i;
                    System.out.println("output : "+ sum);
                }
            }
        };

        Future future = executorService.submit(runnable);

        try{
            future.get();
            System.out.println("task done");
        } catch (Exception e){
            System.out.println(e.getMessage());
        }

        executorService.shutdown();

    }
}

코드를 수행해보면 아래와 같다.

task is being processed
output : 1
output : 3
output : 6
output : 10
output : 15
output : 21
output : 28
output : 36
output : 45
output : 55
task done

반면 future.get()을 쓰지 않으면 코드가 아래처럼 수행이 된다.

task is being processed
task done
output : 1
output : 3
output : 6
output : 10
output : 15
output : 21
output : 28
output : 36
output : 45
output : 55

future.get()이 블로킹하는 부분을 여기서 확인할 수 있다. 스레드의 작업의 종료를 기다리지 않고 main 스레드가 바로 Syso("task done") 코드를 수행하는 것을 확인할 수 있다.

리턴값이 있는 작업 완료

스레드풀의 스레드가 작업 완료 후 작업 값을 얻어야 한다면 작업 객체를 Callable로 생성하면 된다. 이 경우 리턴 타입은 Callable의 리턴 타입인 제네릭 타입 파라미터 T이다.

다음 예제를 보자.

package org.java.chap12.thread_pool;

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class ThreadPoolWithResult {

    public static void main(String[] args) {

        ExecutorService executorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());

        System.out.println("processing...");

        Callable<Integer> callable = new Callable<Integer>() {

            @Override
            public Integer call() throws Exception {
                int sum = 0;
                for(int i=1;i<=90;i++){
                    sum += i;
                }

                return sum;
            }
        };

        Future<Integer> result = executorService.submit(callable);

        try{
            int sum = result.get();
            System.out.println("result returned : "+sum);
            System.out.println("process done");

        } catch (Exception e){
            System.out.println(e.getMessage());
        }
        executorService.shutdown();
    }
}

Callable의 리턴 타입을 Integer로 정했기 때문에 Future도 같은 타입으로 출력할 수 있다.

작업 처리 결과를 외부 객체에 저장하기

스레드의 작업 처리 결과를 외부 객체에 저장해야할 경우도 있다. 예컨대 한 스레드의 작업 처리를 완료하고 다른 스레드의 결과물과 취합해야 할 때처럼 말이다. 이럴 때는 값을 저장할 수 있는 임의의 객체를 만들어(Result) submit(Runnable, Result)를 이용하면 된다. Result는 대개 공유 객체가 되는데, 스레드에서 결과를 저장하기 위해서 사용되어야 하므로 생성자를 통해 Result 객체를 주입받도록 해야 한다.

class Task implements Runnable {

    Result result;

    public Task(Result result){
        this.result = result;
    }

    @Override 
    public void run(){

    //.. code
    this.result.someMethod(); // result에 처리 결과 저장
    }

}

다음은 두 개의 스레드의 작업 값을 Result 객체에 담는 예제이다.

package org.java.chap12.thread_pool;

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class ThreadPoolWithResult {

    public static void main(String[] args) {

        ExecutorService executorService = 
            Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());

        System.out.println("processing");

        class Task implements Runnable{

            Result result;

            Task(Result result){
                this.result = result;
            }

            @Override
            public void run() {
                int sum = 0;
                for(int i =1;i<=10;i++){
                    sum += i;
                }
                result.addValue(sum);
            }

        }

        Result result = new ThreadPoolWithResult.Result();
        Runnable task1 = new Task(result);
        Runnable task2 = new Task(result);

        Future<Result> future1 = executorService.submit(task1, result);
        Future<Result> future2 = executorService.submit(task2, result);

        try{
            result = future1.get();
            System.out.println(result.accumulatedValue); // 110
            result = future2.get();
            System.out.println(result.accumulatedValue); // 110

        } catch(Exception e){
            e.printStackTrace();
        }

        executorService.shutdown();
    }

    static class Result {

        int accumulatedValue;
        synchronized void addValue(int value){
            accumulatedValue += value;
        }
    }
}

공유 객체인 Result를 만들어서 동기화 메서드를 통해 값을 넣어준다. task1과 2가 모두 result를 참조하고 있기 때문에 addValue가 각각 호출되면서 값이 저장된다.

작업 완료 순으로 통보

스레드는 스케줄링에 따라서 임의 순서대로 동작한다. 따라서 작업 요청 순서대로 작업 처리가 완료된다고 보장할 수는 없다. 여러 개의 작업들이 순차적으로 처리될 필요가 없고, 처리 결과도 순차적으로 이용할 필요가 없다면 작업 처리가 완료된 것부터 결과를 얻어 이용하면 된다. 스레드풀에서 작업 처리가 완료된 것만 통보받고 싶다면 CompletionService 인터페이스를 이용하면 된다. 인터페이스에서는 poll(), take()를 제공한다.

• Future<V> poll(): 완료된 Future을 가져옴. 완료된 작업이 없으면 즉시 null 리턴
• **Future<V> take():** 완료된 작업의 Future 가져옴. 완료된 작업이 없다면 있을 때까지 블로킹(지연)

CompletionService 는 ExecutorCompletionService<V>를 통해 구현된다. 생성자 매개값으로 ExecutorService를 제공하면 된다.

ComopletionService completionService = ExecutorCompletionService<V>(executorService);

위 인터페이스의 메서드를 이용하려면 Future 가 있어야 하므로, 스레드풀에 작업을 추가할 때 submit()의 리턴값이 있는 메서드 오버로딩을 이용해야 한다.

다음은 take()를 이용해 스레드 결과값을 얻는 예제이다.

public class Test {
    public static void main(String[] args) {

        ExecutorService executorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());

        CompletionService<Result> completionService = new ExecutorCompletionService<>(executorService);

        System.out.println("submit tasks");

        for(int i =0;i<3;i++) {

            completionService.submit(new Callable<Result>() {

                @Override
                public Result call() throws Exception {

                    Result result = new Result();
                    result.threadName = Thread.currentThread().getName();

                    for(int i=1;i<=10;i++)
                        result.val += i;

                    return result;
                }

            });
        }

        System.out.println("take result from completed task");

        executorService.submit(new Runnable() {

            @Override
            public void run() {

                while(true){
                    try{
                        Result result;
                        Future<Result> future = completionService.take();

                        result = future.get();
                        System.out.println("result : "+ result.val);
                        System.out.println("threadName : "+ result.threadName);

                    } catch (Exception e){
                        break;
                    }
                }
            }
        });

        try {

            Thread.sleep(3000);

        } catch (Exception e){}

        System.out.println("shutting down");
        executorService.shutdownNow();
    }

    public static class Result{
        String threadName;
        int val;

    }
}

CompletionService 를 구현한 ExecutorCompletionService 는 ExecutorService를 주입받았기 때문에 ExecutorService의 메서드를 사용할 수 있다. CompletionService가 총 세 개의 작업을 생성해 큐에 추가한다. 스레드풀에 제한을 따로 걸지 않았으므로 CPU에 여유가 있다면 스레드 3개를 만들어 병렬처리할 것이다.

take()는 작업이 끝날 때까지 블로킹된다. 따라서 future.get()은 블로킹 없이 바로 수행될 것이다. 또한 이 작업은 앱이 실행되는 동안 계속 수행되어야 하므로, while 루핑으로 스레드풀에서 동작하고 있다가 shutdownNow()가 수행되어서 interruptException를 발생시켰을 때 break하면 된다. 스레드 이름을 확인하기 위해 Callable의 리턴값을 이름과 값을 담을 수 있는 객체 Result로 설정했다.

코드를 실행하면 다음과 같은 결과가 나온다.

submit tasks
take result from completed task
result : 55
threadName : pool-1-thread-3
result : 55
threadName : pool-1-thread-2
result : 55
threadName : pool-1-thread-1
shutting down

스레드 3, 2, 1 순으로 작업이 완료된 것을 확인할 수 있다. 스레드 순서는 코드를 수행할 때마다 당연히 바뀐다. 작업은 스레드 스케줄링에 의해 작동하기 때문이다.

콜백 방식의 작업 완료 통보

앞에서는 작업이 완료될 때까지 코드 수행을 블로킹하는 메서드 get()을 통해서 작업 완료를 확인하는 방법을 알아보았다. 이번에는 콜백 방식을 통해서 작업 완료를 확인해본다.

이름만 들어도 대충 두 방법의 차이가 느껴질 것이다. 콜백은 작업 요청을 호출한 스레드가 작업 중인 스레드의 결과를 기다리지 않고 다른 작업을 계속할 수 있다. 작업이 끝나면 스레드에서 콜백 메서드로 결과를 알려주기 때문이다.

스레드풀을 구현하고 있는 ExecutorService에서는 이런 콜백 메서드 기능이 없으므로 Runnable을 구현할 때 콜백 기능을 함께 구현해야 한다. 이것은 직접 개발자가 구현할 수도 있겠지만, java.nio.channels.CompletionHandler를 이용하면 좀 더 편하게 할 수 있다. 해당 인터페이스는 비동기 통신에서 콜백 객체를 만들 때 사용한다. 기본적인 사용 코드는 아래와 같다.

CompletionHandler<V, A> completionHandler = new CompletionHandler<V, A>() {

    @Override
    public void completed(V result, A attachment) {

    }

    @Override
    public void failed(Throwable exc, A attachment) {

    }
};

각 메서드는 작업이 정상 처리 되었을 때와 실패했을 때를 호출되는 콜백 메서드이다. V 타입 파라미터는 리턴 타입이고, A는 첨부값의 타입이다. 다음 예제를 보자.

public class CallbackExam {

    private ExecutorService executorService;

    public CallbackExam(){
        this.executorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
    }

    private CompletionHandler<Integer, Void> callback = new CompletionHandler<Integer, Void>() {

        @Override
        public void completed(Integer result, Void attachment) {
            System.out.println("task completed. the result : "+ result);
        }

        @Override
        public void failed(Throwable exc, Void attachment) {
            System.out.println("task failed. " + exc.toString());
        }
    };

    public void doWork(final String x, final String y){
        Runnable task = new Runnable() {
            @Override
            public void run() {
                try{
                    int intX = Integer.parseInt(x);
                    int intY = Integer.parseInt(y);
                    int result = intX + intY;
                    callback.completed(result, null);
                } catch (NumberFormatException e){
                    callback.failed(e, null);
                }
            }
        };
        executorService.submit(task);
    }

    public void finish(){
        executorService.shutdown();
    }

    public static void main(String[] args) {

        CallbackExam callbackExam = new CallbackExam();
        callbackExam.doWork("3","3");
        callbackExam.doWork("3","삼");
        callbackExam.finish();

    }
}

String 두 개를 인자로 넣어 각각 파싱했을 때 성공하면 completed(), 실패하면 failed()가 호출되도록 한 코드이다. 결과는 다음과 같이 출력된다.

task completed. the result : 6
task failed. java.lang.NumberFormatException: For input string: "삼"

source: https://github.com/thom-droid/basic-java/tree/master/src/org/java/chap12/thread_pool

*reference *: 「이것이 자바다」, 신용권

스레드 그룹은 관련된 스레드를 묶어서 관리할 목적으로 이용한다. JVM이 실행되면 system 스레드 그룹을 만들고, JVM 운영에 필요한 스레드들을 생성해서 system 스레드 그룹에 포함시킨다. 그리고 system의 하위 스레드 그룹으로 main을 만들고 메인 스레드를 main 스레드 그룹에 포함시킨다.

스레드는 반드시 하나의 스레드 그룹에 포함되고, 메서드를 통해서 스레드의 그룹을 지정해주지 않으면 기본적으로 자신을 생서한 스레드와 같은 스레드 그룹에 속하게 된다.

스레드 그룹 이름 얻기

ThreadGroup group = Thread.currentThread().getThreadGroup();
String groupName = group.getName();

static method인 getAllStackTraces()를 이용하면 현재 애플리케이션에서 실행 중인 모든 스레드의 정보를 Map 형태로 얻어올 수 있다.

public class AutoSaveApp {
    public static void main(String[] args) {
        AutoSaveThread autoSaveThread = new AutoSaveThread();
        autoSaveThread.setDaemon(true);

        autoSaveThread.start();

        try{
            Thread.sleep(3000);
        }catch (InterruptedException e){}

        Map<Thread, StackTraceElement[]> threadMap = Thread.getAllStackTraces();
        Set<Thread> threadSet = threadMap.keySet();

        for (Thread t : threadSet){
            System.out.println("thread name : " +t.getName());
                        System.out.println("thread group : " +t.getThreadGroup().getName());
            System.out.println("is daemon? : " +t.isDaemon());
        }

        System.out.println("main thread now shutting down. Daemon also stops");

    }
}

아래 코드만 출력한 결과는 다음과 같다.

thread name : Attach Listener
thread group : system
is daemon? : true

thread name : Finalizer
thread group : system
is daemon? : true

thread name : Monitor Ctrl-Break
thread group : main
is daemon? : true

thread name : Thread-0
thread group : main
is daemon? : true

thread name : main
thread group : main
is daemon? : false

thread name : Signal Dispatcher
thread group : system
is daemon? : true

thread name : Reference Handler
thread group : system
is daemon? : true

GC를 담당하는 Finalizer 스레드를 비롯한 일부 스레드들이 system 그룹에 속하고, main은 main스레드 그룹에 속해있다.

스레드 그룹 생성

ThreadGroup을 생성하는 생성자는 두 가지가 있다.

ThreadGroup(String name);
ThreadGroup(ThreadGroup parent, String name);

첫 번째 생성자는 이름만 지정하는 것이고, 두 번째 생성자는 부모 스레드 그룹을 지정하는 것이다. 부모 스레드 그룹을 명시하지 않고 스레드 그룹을 생성하면, 이 스레드 그룹을 생성한 스레드의 하위 스레드 그룹이 된다. 예를 들어 main 스레드에서 new ThreadGroup("threadGroup1")을 호출한 뒤 getThreadGroup().getName()의 리턴값은 "main"이 된다.

새로운 스레드를 스레드 그룹에 포함 시키려면 스레드 클래스의 생성자 오버로딩을 이용하면 된다. 네 가지가 있다.

Thread(ThreadGroup group, Runnable target);
Thread(ThreadGroup group, Runnable target, String name);
Thread(ThreadGroup group, Runnable target, String name, long stackSize);
Thread(ThreadGroup group, String name);

stackSize는 JVM이 이 스레드에 할당할 스택 사이즈를 의미한다.

스레드 그룹 interrupt()

스레드 그룹으로 스레드를 관리하면 어떤 점이 좋을까? 스레드 그룹에서 제공하는 interrupt()를 호출하면 그룹 내 모든 스레드를 일괄적으로 interrupt할 수 있다. 스레드 그룹의 interrupt()는 내부적으로 그룹에 포함된 모든 스레드의 interrupt()를 호출한다.

다만 앞서 학습한 것처럼 interrupt()는 스레드가 실행 대기 또는 실행 중이라면 예외를 발생시키지 않으므로 그룹에서 interrupt()해도 모든 스레드가 종료되지 않을 수 있다. 따라서 안전한 종료를 위해서는 개별 스레드가 예외 처리를 해야 한다. 아래는 ThreadGroup.interrupt() 코드이다.

public final void interrupt() {
        int ngroupsSnapshot;
        ThreadGroup[] groupsSnapshot;
        synchronized (this) {
            checkAccess();
            for (int i = 0 ; i < nthreads ; i++) {
                threads[i].interrupt();
            } // 각 스레드의  interrupt() 호출

            ngroupsSnapshot = ngroups;
            if (groups != null) {
                groupsSnapshot = Arrays.copyOf(groups, ngroupsSnapshot);
            } else {
                groupsSnapshot = null;
            }
        }
        for (int i = 0 ; i < ngroupsSnapshot ; i++) {
            groupsSnapshot[i].interrupt();
        }
    }

이 외에도 그룹에 속한 모든 스레드를 제거하는 destroy(), 스레드를 추가하는 add(), 하나의 스레드만 제거하는 remove() 등 다양한 메서드가 제공된다. 다음 예제에서는 스레드 그룹을 통해 일괄적으로 스레드를 종료시키는 기능을 구현해본다.

package org.java.chap12.thread_group;

public class AThread extends Thread {

    public AThread(ThreadGroup parent, String threadName){
        super(parent,threadName);
    }

    @Override
    public void run() {
        while(true){
            try{
                System.out.println(getName() +  " is running");
                Thread.sleep(1000);
            } catch (InterruptedException e){
                System.out.println(this.getName()+ "is interrupted");
                break; // interrupted로 예외가 발생하면 catch해서 break            }
        }

        System.out.println(this.getName() + " stops");
    }
}

package org.java.chap12.thread_group;

public class ThreadGroupTestApp {

    public static void main(String[] args) {
        ThreadGroup threadGroup = new ThreadGroup("myGroup");
        AThread threadA = new AThread(threadGroup, "threadA"); 
        AThread threadB = new AThread(threadGroup, "threadB"); 

        threadA.start();
        threadB.start();

        System.out.println("main thread list");
        ThreadGroup mainGroup = Thread.currentThread().getThreadGroup();
        mainGroup.list();
        System.out.println();

        try{
            Thread.sleep(3000);
        } catch (InterruptedException e){}

        System.out.println("thread group interrupts all threads");
        threadGroup.interrupt();
    }
}

main thread list
threadB is running
threadA is running
java.lang.ThreadGroup[name=main,maxpri=10]
    Thread[main,5,main]
    Thread[Monitor Ctrl-Break,5,main]
    java.lang.ThreadGroup[name=myGroup,maxpri=10]
        Thread[threadA,5,myGroup]
        Thread[threadB,5,myGroup]

threadA is running
threadB is running
threadA is running
threadB is running
thread group interrupts all threads
threadBis interrupted
threadB stops
threadAis interrupted
threadA stops

코드 수행 결과.

AThread는 Thread의 생성자 오버로딩을 통해서 생성자 호출 시 스레드 그룹과 스레드 이름으로 초기화된다.
앱에서 threadA와 threadB는 "myGroup"이라는 이름을 가진 스레드 그룹에 속하게 된다. 또한 myGroup 스레드그룹은 스레드그룹을 지정하지 않은 채로 main에서 생성되었으므로 main의 하위 그룹이 된다.
AThread에서 InterruptedException 예외를 처리하고 있으므로 3초 뒤 정상적으로 모든 스레드가 myGroup의 interrupt()에 의해서 정상적으로 종료된다.

이번 장에서는 스레드를 그룹으로 묶어 관리하는 스레드 그룹에 대해 알아보았다.
다음 장에서는 스레드의 개수를 제한하고 작업 순서를 관리하여 애플리케이션의 과부화를 막을 수 있도록 도와주는 기능인 스레드풀에 대해 알아보도록 한다.

source: github1 github2
reference: 「이것이 자바다」, 신용권

스레드 실행 순서

스레드를 생성하고 start() 를 호출하면 바로 스레드가 실행될 것 같지만, 사실 실행 대기(Runnable) 상태가 된다. 실행 대기 상태란 스케줄링이 되지 않아서 실행을 기다리고 있는 상태를 말한다.

실행 대기 상태에 있는 스레드 중에서 스레드 스케줄링으로 선택된 스레드가 CPU를 점유하고 run()메소드를 실행한다. 이때를 실행(Running) 상태라고 한다.

실행 상태의 스레드는 run() 메서드를 실행 완료하기 전에 스레드 스케줄링(time slice)에 의해 다시 실행 대기 상태로 돌아갈 수 있다. 그리고 또 다른 스레드가 스케줄링에 의해 실행 상태가 된다. 이렇게 번갈아가며 여러 스레드가 자신의 run() 를 조금씩 실행한다. 실행 상태에서 run() 가 종료되면 스레드의 실행도 멈추게 된다. 이 상태를 종료 상태(Terminated)라 한다.

public static void main(String[] args) throws InterruptedException {
        Thread mainThread = Thread.currentThread();

        Calc calc = new Calc();
        User1 user1 = new User1();
        user1.setCalc(calc);

        user1.start(); // user1 

        User2 user2 = new User2();
        user2.setCalc(calc);

        user2.start(); // user2
        System.out.println(calc.getMemory()); // main

User1 :100 // user1
100 // main
User2 :50 // user2 

public static void main(String[] args) throws InterruptedException {
        Thread mainThread = Thread.currentThread();

        Calc calc = new Calc();
        User1 user1 = new User1();
        user1.setCalc(calc);

        user1.start(); // user1 

        User2 user2 = new User2();
        user2.setCalc(calc);

        user2.start(); // user2
        System.out.println(calc.getMemory()); // main
                **mainThread.sleep(1000);
        System.out.println(calc.getMemory());
}**

User1 :100 // user1
100 // main
User2 :50 // user2
50 // main

보는 것처럼 시간을 조금 두고 다시 calc.getMemory() 를 해보면 값이 변해있다는 걸 확인할 수 있다. 즉 start() 를 호출한다고 해서 바로 스레드가 실행되는 것이 아니라 스레드 스케줄링에 의해서 적절한 시점에 시작되며, 시작하는 시간까지의 차이가 있다는 것이다.

일시정지 상태

스레드의 생명주기는 생성 → 실행대기 → 실행 → 실행 종료이다. 스레드가 실행 대기 상태일 때는 위와 같이 세 가지 상태가 있다.

스레드의 상태를 코드로 확인하고 싶다면 Thread의 getState()를 호출하면 된다. enum 상수 값으로 스레드의 상태를 리턴한다. 각 값이 의미하는 바는 다음과 같다.

• Thread.State.NEW: 스레드 객체가 생성
• Thread.State.RUNNABLE : 실행 대기. 언제든 실행상태가 될 수 있음
• Thread.State.WAITING : 다른 스레드가 통지할 때까지 기다리는 상태
• Thread.State.TIMED_WAITING : 주어진 시간 동안 기다리는 상태
• Thread.State.BLOCKED: 사용하고자 하는 객체의 락이 풀릴 때까지 기다리는 상태
• Thread.State.TERMINATED: 실행을 마친 상태
  
  

스레드의 상태와 관련해서, 아래의 코드를 보자.

public class StatePrintThread extends Thread {

    private Thread target;
    private Thread target2;

    public StatePrintThread(Thread target, Thread target2){
        this.target = target;
        this.target2 = target2;
    }

    @Override
    public void run() {
        while(true){
            Thread.State state = target.getState();
            Thread.State state2 = target2.getState();

            System.out.println("target Thread Name: " +target.getName());
            System.out.println("target2 Thread Name: " +target2.getName());
            System.out.println("current Thread Name: " +Thread.currentThread().getName());

            System.out.println("thread status : " + state);
            System.out.println("thread2 status : " + state2);

            if(state == Thread.State.NEW){
                target.start();
            }

            if(state == Thread.State.TERMINATED){
                break;
            }

            try{
                Thread.sleep(500);
            } catch (Exception e){}
        }
    }
}

public class Target extends Thread {

    @Override
    public void run() {

        System.out.println("here we go");
        Thread thread = Thread.currentThread();
        thread.setName("target");
        System.out.println("thread name: " +thread.getName());
        System.out.println("thread group: " +this.getThreadGroup());
        for(int i = 0; i<100000000; i++){}

        try{
            Thread.sleep(1500);
        } catch (Exception e){}

        for(int i = 0; i<100000000; i++){}

    }
}

public class ThreadStatusApp {
    public static void main(String[] args) {
        StatePrintThread printThread = new StatePrintThread(new Target(), new TestThread());

        printThread.start();

    }
}

target Thread Name: Thread-0
target2 Thread Name: Thread-1
current Thread Name: Thread-2
thread status : NEW
thread2 status : NEW
here we go
thread name: target
thread group: java.lang.ThreadGroup[name=main,maxpri=10]
target Thread Name: target
target2 Thread Name: Thread-1
current Thread Name: Thread-2
thread status : TIMED_WAITING
thread2 status : NEW
target Thread Name: target
target2 Thread Name: Thread-1
current Thread Name: Thread-2
thread status : TIMED_WAITING
thread2 status : NEW
target Thread Name: target
target2 Thread Name: Thread-1
current Thread Name: Thread-2
thread status : TERMINATED
thread2 status : NEW

StatePrintThread가 while문을 돌리는 동안 Target 에서는 1억번 for 루핑, 1.5초 멈추었다가 다시 1억번 for 루핑이 일어난다. 처음 target 스레드가 만들어졌을 때에는 상태가 NEW 이고, 루핑을 통과하면서 일시정지 상태가 되어서 이를 StatePrintThread가 출력하고, 다시 target이 모든 루핑을 통과하여 run() 실행이 끝나 TERMINATED 상태가 되고, 이를 printThread가 출력하고 while 루핑에서 break하고 있다.

Runnable.run()vs. Thread.start()

두 메서드의 가장 큰 차이점은 run()은 메서드가 호출되고 있는 현재 스레드에서 코드를 수행한다는 점이다. 반면 start()가 호출되면 새 스레드가 생기고 그 스레드에서 run()이 수행된다. start() 같은 경우 해당 스레드가 실행되고 있는지 상태를 체크한 뒤에 스레드를 생성하기 때문에 같은 스레드에서 두 번 start()를 호출하면 IllegalThreadStateException()이 발생한다. 반면 run()은 코드만 수행하기 때문에 여러 번 호출해도 상관은 없지만, 새로운 스레드가 생성되지 않기 때문에 run()을 직접 사용할 이유가 없다.

reference:

「이것이 자바다」, 신용권

• Process: 메모리를 할당 받아 애플리케이션을 수행하는 것, 또는 그 애플리케이션이다.

  
  

• Thread: 프로세스 내에서 한 가지 작업을 수행하기 위한 코드의 실행 흐름을 뜻한다. 코드들이 실처럼 이어져 있다고 해서 붙여진 이름이다.

프로세스 간의 작업은 독립적이다. 따라서 한 프로세스가 다른 프로세스의 작업에 영향을 주지 않는다. 간단한 예로 크롬과 사파리를 같이 켜놨을 때 크롬이 오류가 생겨 꺼지더라도 사파리는 문제없이 계속 작동한다. 반면 스레드는 한 프로세스 안에서 발생하기 때문에 하나의 스레드에서 오류가 발생하면 프로세스 자체가 종료될 수 있으므로 다른 스레드에도 영향을 미치게 된다. 크롬을 쓰는데 한 탭에서 에러가 발생하면 크롬 자체가 꺼지는 것과 같다.

메인 스레드

모든 자바 애플리케이션은 메인 스레드에서 main()을 실행하면서 시작된다. 기본적으로 main() 이 실행되면 순차적으로 코드를 수행하고, 코드 수행이 끝나면 실행이 종료된다.
멀티 스레드 작업 환경을 만들면 모든 스레드가 실행 완료될 때까지 프로세스가 종료되지 않는다. 아래는 멀티 스레드를 간략히 도식화한 것이다.

2. 작업 스레드 생성과 실행

멀티 스레드 애플리케이션을 개발하려면 먼저 몇 개의 작업을 병렬로 실행할지 결정하고 작업별로 스레드를 생성해야 한다.

스레드를 생성하는 방법은 크게 두 가지이다.

1. java.lang.Thread를 직접 생성
2. Thread 를 상속하는 서브 클래스를 통해 생성

차례대로 알아보도록 하자.

스레드 생성: Thread 클래스로부터 직접 생성

Thread 클래스를 생성할 때 Runnable를 매개값으로 갖는 생성자를 호출하여 생성하는 방법이다.

Thread thread = new Thread(Runnable target);

Runnable 은 추상 메서드로 run()을 하나 가지고 있다. 따라서 Runnable을 구현하는 클래스에서 오버라이딩하여 스레드에서 작업할 코드를 써주면 된다.

public class Task implements Runnable{

    @Override
    public void run(){

        //..실행할 코드
    }
}

그리고 Runnable을 구현한 클래스를 Thread 생성자의 인자로 넣어주어서 객체를 생성하면된다.

Ruunable task = new Task();
Thread thread = new Thread(task);

익명 구현 객체를 작성하면 구현 클래스를 따로 작성할 필요 없이 코드를 좀 더 간결하게 짤 수 있다.

Thread thread = new Thread(Runnable() {

    public void run(){
        // .. code
    }

}

작업 스레드는 생성되는 즉시 실행되는 것이 아니라 Thread의 start() 를 호출해야 실행된다. 작성한Runnable의 run()을 호출하면 될 것 같지만, 그러면 스레드가 실행되지 않는다. 두 메서드의 차이점은 아래에서 좀 더 자세히 다뤄본다.

0.5초 주기로 비프음을 발생시키면서 동시에 프린팅하는 작업이 있다고 가정하고 코드로 구현해보면 아래와 같다.

public class PrintExample {
    public static void main(String[] args) {
        Toolkit toolkit = Toolkit.getDefaultToolkit();

        for(int i=0 ; i<5 ; i++){
            toolkit.beep();
            try{ Thread.sleep(500);} catch (Exception e){}
        }

        for(int i=0 ;i<5; i++){
            System.out.println("ding");
            try{ Thread.sleep(500);} catch (Exception e){}
        }
    }
}

위 코드에서는 메인 스레드에서만 작업이 실행되고 있다. 따라서 위 코드를 실행하면 0.5초마다 beep()이 5번 수행되고, 이어서 ding이 0.5초 간격으로 5번 출력되는 결과가 나올 것이다. 병렬처리를 위해 작업 스레드를 추가해서 처리해보자. 먼저 Runnable을 구현하고 있는 클래스를 하나 만든다.

public class BeepTask implements Runnable {

    @Override
    public void run() {
        Toolkit toolkit = Toolkit.getDefaultToolkit();
        for(int i=0 ; i<5 ; i++){
            toolkit.beep();
            System.out.println("beep");
            try{ Thread.sleep(500);} catch (Exception e){}
        }
    }

}

public class PrintExample2 {

    public static void main(String[] args) {
        BeepTask beepTask = new BeepTask();
        Thread beepThread = new Thread(beepTask);
        beepThread.start(); // 작업 스레드 시작

        for(int i=0 ;i<5; i++){
            System.out.println("ding");
            try{ Thread.sleep(500);} catch (Exception e){}
        }
    }
}

ding
beep
ding
beep
ding
beep
ding
beep
ding
beep

동시에 작업이 일어나고 있는 것을 확인할 수 있다. 정확한 같은 시간이라기보다 병렬적으로 작업이 수행된다는 것이 좀 더 정확하겠다. 스레드를 실행하더라도 반드시 같은 시점에 동작하지는 않기 때문이다.

BeepTask 와 같은 클래스를 만들지 않고 익명 객체 또는 람다식을 이용해서도 스레드를 작성할 수 있다.

public class PrintExample2 {

    public static void main(String[] args) {
//        BeepTask beepTask = new BeepTask();
//        Thread beepThread = new Thread(beepTask);
//        beepThread.start();

        // anonymous object 이용
        Thread beepThread = new Thread(new Runnable(){
            @Override
            public void run(){
                Toolkit toolkit = Toolkit.getDefaultToolkit();
                for(int i=0 ; i<5 ; i++){
                    toolkit.beep();
                    System.out.println("beep");
                    try{ Thread.sleep(500);} catch (Exception e){}
                }
            }
        });

    // lambda
        Thread beepThread = new Thread(()->{
            Toolkit toolkit = Toolkit.getDefaultToolkit();
                for(int i=0 ; i<5 ; i++){
                    toolkit.beep();
                    System.out.println("beep");
                    try{ Thread.sleep(500);} catch (Exception e){}
                }
        });

        beepThread.start();

        for(int i=0 ;i<5; i++){
            System.out.println("ding");
            try{ Thread.sleep(500);} catch (Exception e){}
        }
    }
}

스레드 생성: Thread 서브 클래스로부터 생성

Thread는 Runnable을 구현하고 있다. 따라서 Thread를 상속하는 클래스를 만들면 Runnable.run()을 재정의할 수 있고, Thread.start()도 사용할 수 있다.

아래는 Thread를 상속하는 서브 클래스로 스레드를 작성하는 예시이다. 생성자를 통해 인자를 받으면 객체의 필드와 비교해서 메세지를 출력하는 스레드이다.

public class WorkThread extends Thread {

    private final int comparison = 80;
    private int number;

    public WorkThread (int number){
        this.number = number;
    }

    @Override
    public void run(){
        String msg = "your num is bigger";
        if(number>comparison){
            System.out.println(msg);
        }

    }
}

public class ThreadExam {

    public static void main(String[] args) {
        WorkThread workThread = new WorkThread(90);
        workThread.start();
    }
}

이 역시 익명 객체로 만들 수 있다.

public class ThreadExam {

    public static void main(String[] args) {
//        WorkThread workThread = new WorkThread(90);
//        workThread.start();

        Thread thread = new Thread(){

          public void run(){
              for(int i=0 ; i<5 ; i++){
                  System.out.println("beep");
                  try{ Thread.sleep(500);} catch (Exception e){}
              }
          }

        };
        thread.start();

        for(int i=0 ;i<5; i++){
            System.out.println("ding");
            try{ Thread.sleep(500);} catch (Exception e){}
        }
    }
}

스레드 이름

스레드는 식별을 목적으로 이름을 가지고 있다. main()은 main 스레드의 이름이고, 개발자가 직접 생성한 스레드는 Thread-n이라는 이름이 설정된다. Thread의 setName(), getName() 통해 이름을 변경하거나 확인할 수 있다. 그런데 두 메서드는 인스턴스 메서드이므로 Thread 객체의 참조가 필요하다. 스레드의 참조를 알 수 없을 때 static method인 Thread.currentThread()을 이용하면 현재 코드를 수행하고 있는 스레드의 인스턴스를 얻을 수 있다.

3. 스레드 우선순위(Concurrency, Parallelism)

멀티 스레드는 동시 또는 병렬적으로 실행된다. 동시성은 싱글 코어에서 멀티 스레드를 실행할 때 각 스레드를 번갈아가며 수행해나가는 것을 말한다 (앞서 잠깐 언급했듯 동시라는 것이 정확히 같은 시간에 일어난다는 것과는 조금 다르다). 동시성은 각 스레드를 조금씩 번갈아가며 빠르게 수행한다. 병렬성은 멀티 코어 상황에서 코어마다 스레드를 담당하여 작업을 한 번에 처리하는 것을 말한다.

작동하는 스레드의 개수가 cpu보다 많을 경우 스레드를 어떤 순서로 동시적으로 실행할 것인지를 정해야 하는데, 이를 스레드 스케줄링이라고 한다. 이 스케줄링에 의해 스레드들은 아주 짧은 시간에 번갈아가면서 해당 스레드의 run()을 조금씩 실행한다.

스레드 스케줄링: priority vs. round robin

자바에는 스케줄링에 두 가지 개념이 있다.

• Priority
  우선순위를 정해 우선순위가 높을수록 실행 상태를 더 많이 가지도록 한다. 1부터 10까지 개발자가 부여할 수 있기 때문에 개발자가 스레드를 제어할 수 있다. Thread.setPriority()를 통해서 우선순위를 설정할 수 있으며, 설정하지 않았을 때 스레드는 default로 5의 우선순위를 가진다. 값을 설정할 때에는 Thread에 제공되어 있는 상수를 이용해도 된다.

  
  ``` java Thread.setPriority(Thread.MAX_PRIORITY); // 10 Thread.setPriority(Thread.NORM_PRIORITY); // 5 Thread.setPriority(Thread.MIN_PRIORITY); // 1 ```
  

• Round-Robin scheduling
  순환할당방식은 시간 할당량(time slice)을 정해서 하나의 스레드를 정해진 시간만큼 실행하고 다른 스레드를 실행하는 방식이다. 이는 JVM에 의해 정해지므로 코드로 제어할 수는 없다.

4. 동기화 메소드와 동기화 블록

다음은 멀티 스레드에서 중요한 기능인 개념인 메서드와 동기화 블럭에 대해 설명한다. 먼저 이 개념들을 왜 사용해야 하는지에 대해서 알아보자.

공유 객체를 사용할 때 주의점

싱글 스레드 프로그램에서는 한 개의 스레드가 객체를 독차지해서 사용하면 되지만, 멀티 스레드 프로그램에서는 여러 스레드가 객체를 공유해서 작업해야 하는 경우가 있다. 이 경우, 스레드 A를 사용하던 객체가 스레드 B에 의해 상태가 변경될 수 있기 때문에 스레드 A가 의도했던 것과는 다른 결과를 산출할 수도 있다.

User1이 Calculator라는 객체의 a 필드를 100이라고 저장한다고 하자. 그런데 User1가 스레드를 끝내기 전에 User2가 해당 객체의 a 필드를 다시 50으로 저장해버렸다. User1가 작업을 끝내고 a 필드를 출력하면 100이 정상적으로 출력될까? 아래 코드는 위 내용을 표현하고 있다.

package org.java.chap12.multi_threads;

public class Calc {

    private int memory;

    public int getMemory(){
        return this.memory;
    }

    public void setMemory(int memory){
        this.memory = memory;
        try{
            Thread.sleep(2000);
        } catch (Exception e){}
        System.out.println(Thread.currentThread().getName() + " :"+this.memory);
    }
}

package org.java.chap12.multi_threads;

public class User1 extends Thread {

    private Calc calc;

    public void setCalc(Calc calc){
        setName("User1");
        this.calc = calc;
    }

    public void run(){
        calc.setMemory(100);
    }
}

package org.java.chap12.multi_threads;

public class User2 extends Thread{

    private Calc calc;

    public void setCalc(Calc calc){
        setName("User2");
        this.calc = calc;
    }

    public void run(){
        calc.setMemory(50);
    }
}

package org.java.chap12.multi_threads;

public class SharedObject {

    public static void main(String[] args) {
        Calc calc = new Calc();
        User1 user1 = new User1();
        user1.setCalc(calc);
        user1.start();

        User2 user2 = new User2();
        user2.setCalc(calc);
        user2.start();

    }
}

50
50

위 코드에서는 user1과 user2라는 스레드가 있고 두 스레드 모두 Calc 객체를 공유 참조하고 있다. user1이 먼저 실행되어서 Calc 객체의 memory 필드의 값을 100으로 설정했다. 그런데 user2 스레드가 시작되고 값을 50으로 설정하자 두 스레드 모두에서 memory 값이 50으로 변경되었다.

동기화 메서드 및 동기화 블록

위와 같이 멀티 스레드 상황에서 객체를 공유할 때, 한 스레드가 작업 중인 내용을 다른 스레드가 변경할 수 없게 하려면 객체에 잠금을 걸어서 다른 스레드가 사용할 수 없도록 해야 한다.
멀티 스레드에서 단 하나의 스레드만 실행할 수 있는 코드 영역을 임계 영역(critical section)이라고 한다. 자바는 임계 영역을 지정하기 위해 synchronized 메서드와 동기화 블록을 제공한다. 스레드가 객체 내부의 동기화 메서드 또는 블록에 들어가면 즉시 객체에 잠금을 걸어 다른 스레드가 임계 영역 코드를 실행하지 못하도록 한다.

메서드 선언에 synchronized 키워드를 붙이면 해당 메서드 또는 코드 블록에 들어가는 스레드는 잠금이 걸린다. 해당 키워드는 인스턴스, 정적 메서드 모두에 사용될 수 있다.

public synchronized void method(){
    //.. 단 하나의 스레드만 실행됨
}

public void method(){

    // 여러 스레드가 실행 가능

    synchronized(공유 객체){
        // 하나의 스레드만 실행
    }

    // 여러 스레드 실행 가능
}

그림에서 보는 것처럼 동기화가 걸려있는 블럭이나 메서드는 한 스레드가 사용 중이면 다른 스레드에서 실행할 수 없다. 하지만 일반 메서드는 같이 실행이 가능하다.

이를 이전 예제에 적용해보면 아래와 같다.

public class Calc {

    private int memory;

    public int getMemory(){
        return this.memory;
    }

    public synchronized void setMemory(int memory){
        this.memory = memory;
        try{
            Thread.sleep(2000);
        } catch (Exception e){}
        System.out.println(Thread.currentThread().getName() + " :"+this.memory);
    }
}

각 스레드에서 값을 입력하는 메서드였던 setMemory()에 동기화를 적용했다. 이제 수행 결과를 보자.

public class SharedObject {

    public static void main(String[] args) {
        Calc calc = new Calc();
        User1 user1 = new User1();
        user1.setCalc(calc);
        user1.start();

        User2 user2 = new User2();
        user2.setCalc(calc);
        user2.start();

    }
}

User1 :100
User2 :50

스레드 user1이 값을 입력하는 동안에는 user2스레드에서 setMemory()를 실행하지 않으므로 user1.setMemory()가 정상적으로 100을 출력할 때까지 대기하게 된다. 따라서 user1이 작업을 끝날때까지 안전하게 calc 객체를 사용할 수 있게 된다.

다음은 동기화 메서드가 아닌 동기화 블럭을 통해 동기화를 구현한 것이다.

public void setMemory(int memory){

        synchronized (this){
            this.memory = memory;
//        try{
//            Thread.sleep(500);
//        } catch (Exception e){}
            System.out.println(Thread.currentThread().getName() + " :"+this.memory);
        }

    }

동기화 블럭을 이용하면 해당 블럭에만 동기화를 걸고 나머지 메서드 블럭에는 공동으로 실행할 수 있는 코드를 적어줄 수 있다.

source:

github

github2

reference:

「이것이 자바다」, 신용권

Lombok에서 제공하는 이 어노테이션은 생성자 인자를 메서드 체인을 통해 명시적으로 대입하여 생성자를 호출할 수 있게 빌더 클래스를 생성 해준다. 빌더 클래스와 IDE의 자동 완성 기능을 같이 활용하면 생성자 작성 시 오기입 확률과 인자를 누락할 확률을 획기적으로 낮출 수 있다.

doc을 보면 @Builder는 생성자, 메서드 또는 클래스 레벨에서 쓰일 수 있다고 설명되어 있다. 또한 클래스 레벨에서 쓰일 경우 기본적으로 전체 멤버를 생성자의 매개값으로 갖는 private 생성자를 만들어 준다. 이 생성자는 @XArgsConstructor(NoArgs, RequiredArgs) 또는 어떤 생성자도 클래스 내부에 선언하지 않았을 경우에만 생성된다. 반대로 위의 두 조건 중 하나를 했을 경우, 모든 필드를 매개값으로 하는 생성자를 자동으로 선언해서 사용한다. 따라서 이 경우 All Args Constructor가 없으면 컴파일 에러가 발생한다.
정리하면 @Builder 클래스 레벨에서 쓰려면 All args constructor가 있어야 한다. 이 외의 생성자는 컴파일 에러를 일으킨다.

예를 들어 @NoArgsConstructor 를 쓰고 클래스 레벨의 @Builder를 쓰게 되면 All args constructor 없이 기본 생성자만 선언한 것과 같으므로 컴파일 에러가 뜬다.

그런데 JPA나 json parser와 같은 라이브러리를 쓸 때에는 반드시 클래스에 기본 생성자가 있어야 한다. 이 경우 @NoArgsConstructor를 쓸 수 밖에 없다. 그러면 클래스 레벨에서 @Builder를 쓸 수가 없어진다. 방법은 전체 필드를 사용하는 생성자를 직접 선언하고 그 생성자에 @Builder 어노테이션을 쓰든가, 아니면 @NoArgsConstructor 와 @AllArgsConstructor를 모두 쓰면 된다.

@Builder.Default

Builder 어노테이션은 편리하고 명확하게 객체를 생성할 수 있게 도와준다.

@ToString
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Pojo {

    private String name;
    private String nickname;
    private List<PojoTwo> pojoTwos = new ArrayList<PojoTwo>();

}

public class PojoApp {

    public static void main(String[] args) {
        Pojo pojo = Pojo.builder().name("철수").nickname("짱구친구").build();
        System.out.println(pojo.toString());

    }
}

위의 예시처럼 필드 이름을 명시적으로 넣을 수 있어서 생성자 오버로딩 사용 시 시그니처를 신경쓸 필요가 없어서 좋다. 결과는 다음과 같다.

Pojo(name=철수, nickname=짱구친구, pojoTwos=null)

여기서 빌더 패턴을 통해 인스턴스를 만들 때 특정 필드를 특정 값으로 초기화하고 싶다면 @Builder.Default를 쓰면 된다.

@ToString
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Pojo {

    @Builder.Default
    private String name = "짱구엄마";
    private String nickname;
    private List<PojoTwo> pojoTwos = new ArrayList<PojoTwo>();

}

public class PojoApp {

    public static void main(String[] args) {
        Pojo pojo = Pojo.builder().nickname("짱구친구").build();
        System.out.println(pojo.toString());

    }
}

Pojo(name=짱구엄마, nickname=짱구친구, pojoTwos=null)

이렇게 객체를 원하는 값으로 초기화해서 반환 받을 수 있다. 이번엔 아래 코드의 결과값을 보자.

public class PojoApp {

    public static void main(String[] args) {
        Pojo pojo = Pojo.builder().nickname("짱구친구").build();
        System.out.println(pojo.toString());

        Pojo pojo1 = new Pojo();
        System.out.println(pojo1.toString());

    }
}

Pojo(name=짱구엄마, nickname=짱구친구, pojoTwos=null)
Pojo(name=짱구엄마, nickname=null, pojoTwos=[])

빌더를 통해 만든 객체는 List 필드가 null로 초기화 되었고, 빌더 없이 기본 생성자로 생성한 pojo1의 List 필드는 정상적으로 empty List로 초기화되었다. 클래스에서는 분명히 new ArrayList<>로 초기화를 했는데 왜 이런걸까?

class Example<T> {
       private T foo;
       private final String bar;

       private Example(T foo, String bar) {
           this.foo = foo;
           this.bar = bar;
       }

       public static <T> ExampleBuilder<T> builder() {
           return new ExampleBuilder<T>();
       }

       public static class ExampleBuilder<T> {
           private T foo;
           private String bar;

           private ExampleBuilder() {}

           public ExampleBuilder foo(T foo) {
               this.foo = foo;
               return this;
           }

           public ExampleBuilder bar(String bar) {
               this.bar = bar;
               return this;
           }

           @java.lang.Override public String toString() {
               return "ExampleBuilder(foo = " + foo + ", bar = " + bar + ")";
           }

           public Example build() {
               return new Example(foo, bar);
           }
       }
   }

필드를 사용하는 생성자와 각 필드의 setter 메서드로 구성된 inner 클래스를 하나 만들어서 그 안에서 원본 클래스의 인스턴스를 리턴한다. 여기서 객체 타입의 필드가 있다고 가정하면, 당연히 내부 클래스에서는 이 객체 타입을 초기화하는 코드가 없다. 따라서 null로 초기화 될 것이고, 이 필드를 포함해서 원본 클래스가 만들어지므로 빌더를 통한 객체 생성에서는 객체 타입 필드가 null인 것이다.

이를 해결하기 위해서도 역시 @Builder.Default를 쓰면 된다.

@ToString
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Pojo {

    @Builder.Default
    private String name = "짱구엄마";
    private String nickname;
    @Builder.Default
    private List<PojoTwo> pojoTwos = new ArrayList<PojoTwo>();

}

Pojo(name=짱구엄마, nickname=짱구친구, pojoTwos=[])
Pojo(name=짱구엄마, nickname=null, pojoTwos=[])

두 방식 모두 원하는 대로 초기화가 되었다.

TL; DR 🙄

• @Builder를 클래스 레벨에서 쓰면 모든 필드로 생성자를 생성하는 빌더 생성. 이 때 모든 필드 생성자가 선언되어 있어야 함. 이 생성자 없이 다른 생성자 오버로딩 쓰면 컴파일 에러 발생.

  
  

• 결과적으로는 NoArgsConstructor + AllArgsConstructor + Builder 콤보를 쓰면 됨

  
  

• @Builder.Default는 빌더로 인스턴스 생성 시 초기화할 값을 정할 수 있음. 빌더 패턴을 쓰는데 필드에 객체 타입이 있다면 꼭 써주자.

자바는 클래스와 인터페이스의 메타 데이터를 java.lang.Class의 클래스를 통해 관리한다. 메타 데이터란 클래스 이름, 필드, 생성자, 메서드 등을 말한다.

Class 객체 얻기

Object의 getClass()를 통해 얻을 수 있다. 해당 메서드는 인스턴스를 생성했을 때만 사용할 수 있다. 인스턴스를 통하지 않고 Class의 정적 메서드인 forName() 을 통해 직접 클래스를 얻어오는 방법도 있다. 이 때 forName()의 인자로는 패키지가 포함된 클래스 또는 인터페이스 이름을 넣어주어야 한다.

@CallerSensitive
public static Class<?> forName(String className)
            throws ClassNotFoundException {
    Class<?> caller = Reflection.getCallerClass();
    return forName0(className, true, ClassLoader.getClassLoader(caller), caller);
}

String으로 된 클래스 또는 인터페이스를 찾아 내부적으로 Reflection을 이용하고 있는 걸 알 수 있다.

아래는 간단한 예제이다. 해당 메서드를 이용할 때 인자로 대입된 값으로 클래스를 찾지 못하면 ClassNotFoundException을 발생시키므로 예외처리를 적절히 해주어야 한다.

public class ClassExam {

    public static void main(String[] args) throws ClassNotFoundException {


        Author author = new Author(); 
        Class authorClass = author.getClass(); // 인스턴스 생성하여 Class 객체 얻어오기


        Class clazz = Class.forName("org.java.chap11.apis.clone.Author"); // forName()으로 Class 객체 얻어오기
        System.out.println(clazz.getName());
        System.out.println(Arrays.toString(clazz.getDeclaredMethods()));
        System.out.println(Arrays.toString(clazz.getClasses()));
    }

}

org.java.chap11.apis.clone.Author
[public java.lang.String org.java.chap11.apis.clone.Author.toString(), protected java.lang.Object org.java.chap11.apis.clone.Author.clone() throws java.lang.CloneNotSupportedException, public java.lang.String org.java.chap11.apis.clone.Author.getName(), public java.lang.String org.java.chap11.apis.clone.Author.getId(), public void org.java.chap11.apis.clone.Author.setName(java.lang.String), public java.lang.String org.java.chap11.apis.clone.Author.getCountry(), public org.java.chap11.apis.clone.Biography org.java.chap11.apis.clone.Author.getBiography(), public void org.java.chap11.apis.clone.Author.setCountry(java.lang.String), public java.lang.String org.java.chap11.apis.clone.Author.getAge(), public void org.java.chap11.apis.clone.Author.setBooks(java.lang.String[]), public org.java.chap11.apis.clone.Author org.java.chap11.apis.clone.Author.cloneAuthor(), public void org.java.chap11.apis.clone.Author.setBiography(org.java.chap11.apis.clone.Biography), public void org.java.chap11.apis.clone.Author.setId(java.lang.String), public java.lang.String[] org.java.chap11.apis.clone.Author.getBooks(), public void org.java.chap11.apis.clone.Author.setAge(java.lang.String)]

Reflection

위와 같이 클래스나 인터페이스의 메타 정보를 찾아내는 것을 리플렉션이라고 한다. 위 예시에서 사용한 메서드 말고 다양한 메서드를 통해 클래스의 정보를 알아낼 수 있다.

예를 들어 getDeclaredMethods() 는 클래스 내부에 선언된 생성자의 정보를 배열의 형태로 받아온다. 상속받은 생성자는 무시하는데, 상속된 내용까지 확인하고 싶다면 getMethods() 를 이용하면 된다.

동적 객체 생성

Class 클래스의 newInstance()를 활용하면 런타임 시에 지정해둔 클래스를 동적으로 객체를 생성할 수도 있다.

newInstance()는 두 가지 예외를 발생시킨다. 따라서 예외 처리를 해주어야 한다.

• InstantiationException: 대입된 클래스가 추상 클래스이거나 인터페이스여서 인스턴스화할 수 없는 경우
  
• IllegalAccessException: 클래스나 생성자가 접근제한자로 인해 접근할 수 없을 경우
  

newInstance() 리턴 타입은 Object이므로 생성한 인스턴스를 변수에 저장하기 위해서는 변수 타입에 맞게 캐스팅을 해주어야 한다. 그런데 컴파일 단계에서는 어떤 타입의 변수를 쓸지 알 수가 없으므로 인터페이스를 구현하여 처리한다(구현 클래스의 형태는 인터페이스만 구현하면 형을 다양하게 바꿀 수 있으므로). 아래의 예시를 보자.

public interface TestInterface {

    void method1();
}

public class RuntimeClass1 implements TestInterface{

    @Override
    public void method1() {
        System.out.println("runtime class 1");
    }
}

public class RuntimeClass2 implements TestInterface {

    @Override
    public void method1() {
        System.out.println("RuntimeClass 2");
    }
}

public class NewInstanceExam {

    public static void main(String[] args) {

        try {
            Class clazz = Class.forName("org.java.chap11.apis.clazz.RuntimeClass1");
            TestInterface testInterface = (TestInterface) clazz.newInstance();
            testInterface.method1();
        } catch (ClassNotFoundException | InstantiationException |IllegalAccessException e ){
            e.printStackTrace();
        }

    }
}

runtime class 1

위와 같이 동적으로 생성할 인스턴스를 forName()으로 얻어온 뒤 TestInterface 타입으로 캐스팅해주면 인터페이스를 구현하는 인스턴스를 생성할 수 있다.

source: github

reference: 「이것이 자바다」, 신용권

클라이언트와 서버의 통신 사이에 놓여 있는 서버로, 클라이언트 대신 서버로부터 정보를 얻거나 처리하는 역할을 한다. 소프트웨어 디자인 관점으로 보면, 두 객체 간에 존재하는 인터페이스로써, 보이지 않는 곳에서(behind the scenes) 클라이언트의 요청을 처리하는 위임 객체(agent object)라고 할 수있다.

가장 큰 특장점은 아래와 같다.

• 익명성 (anonymity) 클라이언트의 요청을 프록시에서 받으면, 프록시가 직접 서버와 통신한다. 이를 통해 클라이언트의 public IP를 숨기고 프록시의 IP를 통해 통신할 수 있다.
  
• 캐싱을 이용한 속도 최초 리소스에 대한 요청이 있을 때, 프록시는 해당 요청의 결과를 서버로부터 받아 지정된 곳에 캐싱한다. 같은 요청이 왔을 때 다시 서버로 통신할 필요가 없이, 캐싱된 리소스를 통해 속도를 높일 수 있다. 또한 같은 요청에 대해 매번 서버에 접속할 필요도 줄어들게 되므로 bandwitdth도 줄일 수 있다.
  
• 로깅 요청 IP와 요청된 리소스, 방문 시간 등 다양한 로그를 저장하므로 다양하게 활용할 수 있다.

reference:

• what is a proxy server?
• https://en.wikipedia.org/wiki/Proxy_pattern

객체를 하나 복제하는 것을 말한다. 구현 범위에 따라 thin clone, deep clone가 있다. 복제하고자 하는 클래스는 Cloneable 인터페이스를 구현하여 해당 클래스가 복제 가능하다고 명시해주어야 한다. 그리고 clone() 을 호출할 때에는 CloneNotSupportedException을 예외처리 해주어야 한다.

clone()은 복제한 클래스의 필드값을 복사한다. 정확히는 같은 클래스 타입의 인스턴스를 만들고 필드 내의 필드를 원본 클래스의 값들로 초기화하는 것이다 (primitive의 경우는 값 자체를 복사하고, reference 타입은 reference 번지를 복사해서 대입한다). 따라서 기본적으로는 복제, 원본 간에 동등성이 있으나 동일성은 없다.

x.clone() != x; // true
x.clone().equals(x); // true
x.clone().getClass() == x.getClass(); // true

thin clone

아래는 복제하고자 하는 객체의 멤버들이 모두 primitive인 경우이다. 이런 경우에는 단순한 복사, 얕은 복사를 해도 원본과 복제가 독립적으로 존재한다고 봐도 무방하다.

public class Author implements Cloneable{

    private String id;
    private String name;
    private String age;
    private String country;

    public Author(String id, String name, String age, String country) {
        this.id = id;
        this.name = name;
        this.age = age;
        this.country = country;
    }

    public Author() {
    }

//getter/setter / toString()

public Author cloneAuthor(){
        Author cloned = null;
        try {
            cloned = (Author) this.clone();
        } catch (CloneNotSupportedException e){
            e.printStackTrace();
        }
        return cloned;
    }

위와 같이 clone() 오버라이딩 할 때 위임하는 예외를 잡아주는 코드를 써주면 된다. 그리고 Cloneable 인터페이스를 구현해야 한다.

public class CloneTest {

    public static void main(String[] args) {

        Author author1 = new Author("1","franz kafka","30","czechia");

        Author clonedAuthor = author1.cloneAuthor();
        clonedAuthor.setName("Guy de Maupassant");

        System.out.println(author1.toString());
        System.out.println(clonedAuthor.toString());

                System.out.println(author1.equals(clonedAuthor));
        System.out.println(author1.getClass() == clonedAuthor.getClass());
        System.out.println(author1 == clonedAuthor);

    }
}

Author{id='1', name='franz kafka', age='30', country='czechia'}
Author{id='1', name='Guy de Maupassant', age='30', country='czechia'}

false
true
false

결과는 아래와 같이 나온다. 앞에 설명했듯 원본과 복제는 같은 타입이지만 다른 인스턴스이다.

deep clone

이번엔 아래의 예시를 보자.

public class CloneTest {

    public static void main(String[] args) {

        Author author1 = new Author("1","franz kafka","30","czechia");
        String[] books = {"the Metamorphosis", "a country doctor"};
        author1.setBooks(books);

        Author clonedAuthor = author1.cloneAuthor();

        clonedAuthor.setName("Guy de Maupassant");
        clonedAuthor.getBooks()[0] ="bel ami";

    }
}

original :Author{id='1', name='franz kafka', age='30', country='czechia', books=[the Metamorphosis, a country doctor]}
cloned   :Author{id='1', name='franz kafka', age='30', country='czechia', books=[the Metamorphosis, a country doctor]}

==========before mod============

modification from the cloned

original :Author{id='1', name='franz kafka', age='30', country='czechia', books=[**bel ami**, a country doctor]}
cloned   :Author{id='1', name='Guy de Maupassant', age='30', country='czechia', books=[**bel ami**, a country doctor]}

앞선 예시와 기본 틀은 같지만, book이라는 String[]이 필드로 추가되었다. 배열은 자바에서 reference type에 해당한다. 결과를 보면 primitive인 필드가 수정되었을 경우에 원본과 복제에 독립적으로 값이 수정되지만, 복제 객체에서 참조하고 있는 객체의 값을 bel ami 로 수정했더니 원본도 값이 변하는 걸 확인할 수 있다.

이것은 원본과 복제 모두 같은 배열의 참조 값을 가지고 있기 때문이다. 현재 참조된 객체는 mutable하므로 한 쪽에서 값을 수정하면 참조하고 있는 다른 한 쪽에도 영향을 미치게 된다. 즉, 원본과 복제 객체의 완벽한 독립이 이루어지지 않는다.

이것을 해결하려면 clone()을 오버라이딩하여, 복제 시에 reference 타입의 멤버들도 새로 만들어 해당 참조 값을 대입해주어야 한다. 아래의 코드는 Author 클래스에 Object.clone()을 오버라이딩 한 것이다.

    @Override
        protected Object clone() throws CloneNotSupportedException {
        // thin clone
          Author cloned = (Author) super.clone();
          // deep clone
          cloned.books = Arrays.copyOf(this.books, this.books.length);
          cloned.biography = new Biography();
          return cloned;
       }

primitive 또는 immutable한 필드는 Object.clone()을 통해 복제를 한다. 그리고 mutable한 reference type의 필드인 books 배열과 Biography의 경우 새로 참조를 만들어 복제 객체의 해당 필드에 대입해준다. 이제 타입은 같지만 다른 인스턴스인 객체를 참조하게 된다.

마지막으로 수정된 코드는 아래와 같다.

public class CloneTest {

    public static void main(String[] args) {
                // author1 
        Author author1 = new Author("1","franz kafka","41","czechia");
        String[] books = {"the Metamorphosis", "a country doctor"};
        author1.setBooks(books);

        Biography bio1 = new Biography("1883","1924");
        author1.setBiography(bio1);

                // clone 
        Author clonedAuthor = author1.cloneAuthor();

                // modification in clone
        clonedAuthor.setName("Guy de Maupassant");
        clonedAuthor.setAge("43");
        clonedAuthor.getBooks()[0] ="bel ami";
        clonedAuthor.getBiography().setBirth("1850");
        clonedAuthor.getBiography().setDeath("1893");

    }
}

출력하면 아래와 같다.

original :Author{id='1', name='franz kafka', age='41', country='czechia', books=[the Metamorphosis, a country doctor], biography=Biography{death='1924', birth='1883'}}
cloned   :Author{id='1', name='franz kafka', age='41', country='czechia', books=[the Metamorphosis, a country doctor], biography=Biography{death='null', birth='null'}}

==========before mod============

modification from the cloned

original :Author{id='1', name='franz kafka', age='41', country='czechia', books=[the Metamorphosis, a country doctor], biography=Biography{death='1924', birth='1883'}}
cloned   :Author{id='1', **name='Guy de Maupassant**', age='43', country='czechia', books=[**bel ami, a country doctor**], biography=Biography{**death='1893', birth='1850'}**}

위와 같이 복제된 객체에서의 변경은 복제 객체 내에서만 일어난 것을 확인할 수 있다.

source: github

reference: 「이것이 자바다」, 신용권

자바 진영 ORM 기술 표준. hibernate를 비롯한 다른 ORM 프레임워크의 기능을 추상화하여 만든 인터페이스, ORM 표준 기술 명세이다.

1. JPA의 등장

기존 애플리케이션 개발 방식에서는 DB와 통신하기 위해서 데이터 접근 계층에 많은 SQL 관련 코드를 작성해야 했다. 쿼리를 일일이 작성하는 것은 물론이고, 요구사항이 바뀌는 경우 DTO부터 SQL 쿼리를 모두 수정해야 해서 유지보수도 힘들었다. 애플리케이션 개발은 점점 데이터 코드 작성에 의존적이게 되었다. 실제로 나도 myBatis로 개발을 할 때 로직보다 SQL을 짜는 데에 더 많은 시간을 보내면서 '이게 개발인가?' 싶은 생각도 들었었다.

1.1 패러다임 불일치

이러한 문제는 객체 지향적인 개발 언어와 테이블의 관계로 구성된 데이터베이스의 근본적인 지향점이 다르기 때문에 발생했다. 객체 지향 언어에서는 상속, 추상, 다형성 등 객체 간의 복잡성을 통해 데이터를 관리한다. 반면 관계형 데이터베이스는 이러한 개념을 거의 사용하지 않으며, 데이터 자체에 중점을 두고 구조화되어 있다.

1.1.1 상속

자바에서는 상속을 통해서 객체 간의 관계를 표현한다. 하지만 DB에 저장될 때 이를 구현하려면 번거롭다. 예를 들어 Cuisine이라는 슈퍼 클래스가 있고 서브 클래스 Chinese, Korean, Japanese가 각각 이를 상속한다고 해보자. 기존의 JDBC template으로 Chinese 객체를 저장한다고 하면, Chinese의 내용과 Cuinese을 따로 SQL로 저장해야 할 것이다. 조회하는 것은 더 귀찮다. 저장한 Chinese 객체를 찾으려면 Cuisine과 Chinese 테이블을 조인해서 조회한 결과를 Chinese 객체를 반환하는 코드를 짜야할 것이다.

1.1.2 연관관계

자바와 RDBMS에서 모델링의 가장 큰 차이점은 객체는 참조를 사용하지만 RDBMS는 외래키를 사용한다는 점이다. 외래키로는 관련된 테이블을 모두 조회할 수 있지만, 자바에서는 참조를 가진 쪽만 데이터에 접근할 수 있다. 객체도 테이블처럼 cuisineId와 같이 외래키와 동일한 필드를 객체 내에 직접 저장하는 방법을 생각해볼 수 있지만, cuinse의 정보를 불러올 때 결국 chinese.getCuisineId()를 사용하고 다시 해당 id로 DB에 접근해야 하므로 Cuisine과 Chinese 간의 관계를 제대로 표현할 수 없는, 객체지향적이지 못한 코드를 써야한다.

Chinese를 조회하는 코드를 보면 아래와 같다.

public class Chinese extends Cuisine{

    String id;
    String cuisineId;
    String ingredient;

}

String cuisineId = chinese.getCuisineId();
Cuinise cuisine = dao.selectCuisine(cuisineId);

좀 더 객체 지향적으로 모델링을 한다고 하면 아래와 같이 관계된 객체의 참조값을 조회하면 될 것이다.

Cuisine cuisine = dao.selectCuisine(chinese.getCuisine());

JPA를 통해 엔티티 간의 관계를 설정해놓고, 아래와 같이 수행하면 chinese에 cuisine으로 접근할 수 있는 참조값을 외래키로 변환하여 적절하게 insert 쿼리를 작성하여 저장해준다.

chinese.setCuisine(cuisine);
jpa.persist(chinese);

Chinese chinese = jpa.find(Chinese.class, chineseId);
Cuisine cuisine = chinese.getCuisine();

1.2 객체 그래프 (object graph) 탐색

객체 간의 관계를 통해 표현되는 네트워크, 관계도. 객체 참조를 통해 객체를 찾는 것을 객체 그래프 탐색이라고 한다. 예를 들어 Member, Team, Order, OrderItem 등 여러 객체가 관계를 맺고 있을 때,

    member.getOrder().getOrderItem()...

이와 같은 방식으로 객체 그래프를 탐색할 수 있다.

SQL을 사용하여 직접 객체 그래프를 탐색하게 되면 탐색할 범위를 정해놔야 한다. 위 코드를 쿼리로 보면 아래와 같이 짜야 한다.

SELECT member.*, order.*, orderItem.*
FROM member m
JOIN order o ON o.id = m.order_id 
....

이와 같은 상황에서 검색할 컬럼이 하나 더 있거나, order_id를 통해 또 다른 테이블의 정보를 얻어오고자 한다면 쿼리 일부와 dao 일부를 모두 건드려야 할 것이다.

따라서 아래와 같은 코드가 있다고 할 때

Member member = dao.find(memberId);
member.getOrder();
member.getOrder().getOrderItem();

1.2.1 JPA에서의 객체 그래프 탐색

JPA에서는 객체를 사용하는 시점에 적절히 쿼리를 만들어 수행해준다. 그래서 따로 조인 쿼리를 짜지 않더라도 관계 설정이 되어 있는 여러 엔티티에서 다른 엔티티를 호출하는 메서드를 사용하면, 해당 엔티티의 정보를 객체로 반환 받을 수 있다. 따라서 연관관계를 맺어놓은 객체들을 마음껏 탐색할 수 있게 된다. 이것이 가능한 것은 프록시 객체를 이용한 지연 로딩 기능이 있기 때문인데, 이는 뒤에서 천천히 설명한다.

1.3 동일성 비교

같은 조건으로 데이터를 검색했을 떄, 기존의 JDBC에서는 동일성을 보장하기 위해서는 대부분의 객체마다 equals()와 hashcode()를 오버라이딩해서 사용하여야 했다.

public Member getMember(String memberId){

    String sql = "SELECT * FROM MEMBERS WHERE MEMBER_ID = ?";

    /..../
    return new Member(....);
}

String memberId = "100";
Member m1 = dao.getMember("100");
Member m2 = dao.getMember("100");

하지만 JPA는 같은 트랜잭션에서 같은 객체가 조회되는 것을 보장한다.

String memberId = "100";
Member m1 = jpa.find(Member.class, memberId);
Member m2 = jpa.find(Member.class, memberId);

위와 같은 코드에서 m1==m2는 true를 리턴한다. 이는 JPA에서 사용하는 영속성 컨텍스트를 통해 가능한 것인데, 자세한 것은 이 다음 장에서부터 확인할 수 있다.

어노테이션은 메타데이터와 비슷하다. 적용되는 클래스나 메서드, 파라미터 등 자바 내에서 사용되는 다양한 데이터에 추가적인 정보를 제공한다. 이런 특징을 이용해서 특정 어노테이션을 붙인 파라미터를 아규먼트 리졸버로 처리한다든가 활용할 수 있는 방법들이 있다.

용도는 크게 아래와 같이 세 가지이다.

• 컴파일러에게 코드 문법 에러 체크하도록 정보 제공
• 빌드나 배치 시 코드를 자동으로 생성할 수 있도록 정보를 제공
• 런타임 시 특정 기능하도록 정보 부여
  
  # 어노테이션 타입 정의와 적용

public @interface AnnotationName{}

interface 키워드 앞에 @를 붙여 선언할 수 있다.

어노테이션 엘리먼트

public @interface AnnotationName{

    String element1();
    int element2() default 5;

}

특이한 점은 메서드를 선언하는 것처럼 선언 후 소괄호를 붙여주어야 한다는 것이다.

또한 엘리먼트 별로 default라는 키워드로 초기값을 설정해줄 수 있다. default 값을 선언해놓으면 해당 엘리먼트를 명시하지 않거나 엘리먼트 표기 후 값을 넣징 않았을 경우 default 값이 적용된다. 하지만 반대로 default를 선언하지 않은 엘리먼트를 사용할 때 값을 적지 않으면 컴파일 에러가 발생한다.

기본적으로 어노테이션을 사용하는 방법은 아래와 같다.

    @AnnotationName
       (element1 = "value must be assigned", element2=3 // 기재 안 할 경우 5)
       public void doSomething(){

       }

또한 value라는 엘리먼트는 이름을 명시하지 않아도 바로 쓸 수도 있다. Spring에서 많이 쓰는 @PathVariable이나 @RequestMapping에 변수명이나 주소를 바로 쓸 수 있는 것도 사실은 value 엘리먼트를 생략할 수 있기 때문이다.

public @interface AnnotationName{

    String value();

}


@AnnotationName("value" // 또는 value = "value"로 적어도 됨)
public void doSomething(){

    //... code here

}

어노테이션 적용 대상

@Target 이라는 어노테이션을 통해 특정 어노테이션이 적용될 범위를 지정할 수 있다. @Target 어노테이션에는 ElementType이라는 enum 타입의 엘리먼트가 있어서 이를 통해 명시적으로 적용 범위를 표시할 수 있다. ElementType enum의 필드는 아래와 같다.

public enum ElementType {
    /** Class, interface (including annotation type), or enum declaration */
    TYPE,

    /** Field declaration (includes enum constants) */
    FIELD,

    /** Method declaration */
    METHOD,

    /** Formal parameter declaration */
    PARAMETER,

    /** Constructor declaration */
    CONSTRUCTOR,

    /** Local variable declaration */
    LOCAL_VARIABLE,

    /** Annotation type declaration */
    ANNOTATION_TYPE,

    /** Package declaration */
    PACKAGE,

    /**
     * Type parameter declaration
     *
     * @since 1.8
     */
    TYPE_PARAMETER,

    /**
     * Use of a type
     *
     * @since 1.8
     */
    TYPE_USE
}

명시적으로 표현되어 있어서 따로 부연할 부분은 없는 것 같다. 예를 들어 ElmentType.METHOD라고 명시한다면 해당 어노테이션은 method에만 적용된다는 의미이다.

@Target 어노테이션에는 위에서도 언급한 기본 엘리먼트인 value 엘리먼트가 있다. ElementType 배열 타입 형태이다. 따라서 여러 값을 한 번에 지정할 수 있다. 아래는 @Target의 api doc 설명이다.

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface Target {
    /**
     * Returns an array of the kinds of elements an annotation type
     * can be applied to.
     * @return an array of the kinds of elements an annotation type
     * can be applied to
     */
    ElementType[] value();
}

@Target({ElementType.PARAMETER, ElementType.FIELD})
public @interface AnnotationName{
    elements...
}

해석하자면 @Target으로 설정된 @AnnotationName 은 파라미터와 필드에만 적용될 수 있다는 의미이다.

어노테이션 유지 정책 (@Retention)

어노테이션을 어느 범위까지 유지할 것인가에 대해 설정하는 어노테이션이다.

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface Retention {
    /**
     * Returns the retention policy.
     * @return the retention policy
     */
    RetentionPolicy value();
}

@Target과 마찬가지로 RetentionPolicy 열거 타입의 엘리먼트를 기본적으로 가지고 있다. 아래는 api doc이다.

public enum RetentionPolicy {
    /**
     * Annotations are to be discarded by the compiler.
     */
    SOURCE,

    /**
     * Annotations are to be recorded in the class file by the compiler
     * but need not be retained by the VM at run time.  This is the default
     * behavior.
     */
    CLASS,

    /**
     * Annotations are to be recorded in the class file by the compiler and
     * retained by the VM at run time, so they may be read reflectively.
     *
     * @see java.lang.reflect.AnnotatedElement
     */
    RUNTIME
}

• SOURCE: 소스코드 상태에서만 유지. 컴파일 될 때 유지 안됨.
• CLASS: 바이트코드까지 정보 유지. 설정 안되어 있을 때 기본 동작. Reflection으로 읽어올 수 없음.
• RUNTIME: 바이트 코드 까지 어노테이션 정보 유지. Reflection으로 읽어올 수 있음.

Reflection은 런타임 시에 클래스 메타 정보 얻는 기능이다. Class 클래스와 java.lang.reflect의 메서드를 통해 특정 클래스나 인터페이스의 메타데이터(필드, 메서드, 생성자 정보 등)를 얻어오는 것을 말한다. 어노테이션의 유지 정책이 RUNTIME인 경우가 많다.

런타임 시 어노테이션 정보 사용하기

예제에 사용된 코드

reference:

• 신용권, 이것이 자바다

Set

List, Map과 함께 대표적인 Java 인터페이스이다. List와 함께 Collection interface를 상속하는 인터페이스다. 집합이라는 의미이고, 수학에서 쓰이는 용어와 같은 뜻을 가지고 있다.

Set의 특징

Set 인터페이스의 가장 큰 특징은 List 인터페이스와 달리 unordered이다. 따라서 인덱스를 관리하지 않기 때문에 값을 저장하고 값을 불러올 때 순서를 고려하지 않는다. 또한 duplicate를 허용하지 않는다. 같은 데이터가 입력되었을 때 중복저장하지 않는다. null은 최대 하나만 입력을 허용한다.

Index가 관리되지 않기 때문에 set을 검색하게 될 경우 Iterator 인터페이스를 주로 활용한다. 활용은 다른 collection interface와 동일하다.

Set<String> set = new HashSet<>();
set.add("des bonbons");
set.add("le chocolat");
...
Iterator<String> itr = set.iterator();
while(itr.hasNext()){
    String str = itr.next();
}

또는 for each를 통해 iteration하면 된다

for(String str : set){
    syso(str);
}

주의할 것은 Iterator 인터페이스의 remove()를 사용했을 때 실제 set에서 데이터가 지워진다는 점이다.

while(itr.hasNext()){
    String str = itr.next();
    if(str.equals("des bonbons")){
        itr.remove(); // set에서 삭제
    }
}

물론 set에도 remove()가 있어서 특정 인자를 넣게 되면 해당 인자에 해당하는 데이터가 지워지게 된다.

HashSet

Set 인터페이스의 가장 대표적인 구현 클래스이다. HashTable, 정확히는 HashMap을 기반으로 한 클래스이다. 따라서 bucket, capacity와 같은 개념들이 그대로 적용된다.

참고: HashMap

HashMap과 마찬가지로 데이터를 저장할 때 hashCode()로 hash code를 얻어내고, 이를 토대로 이미 저장되어 있는 데이터의 hash code를 비교한다. 만약 새로 저장하려는 값의 hash code가 이미 존재하고 있으면 equals()로 두 값을 비교하고, 같은 값이면 저장하지 않는다. 개발자가 지정한 DTO의 경우 이 두 메서드를 overriding하여 다른 인스턴스여도 같은 값을 가진 객체이면 중복 저장하지 못하게 하는 이유이다. 역시 HashMap의 자료를 참고하면 이해가 될 것이다.

hash code로 값을 저장, 접근하기 때문에 add(), remove(), contains(), size()에 대해서는 시간 복잡도가 상수값을 갖는다.

HashMap에서처럼 capacity의 threshold에 다다르게 되면 doubling 한 뒤 rehashing되므로, iteration 성능이 중요한 요소일 경우 capacity를 높게 설정해주는 것이 좋을 수 있다.

또한 동기화처리가 내부적으로 되어있지 않기 때문에 multi-thread 환경에서 set에 대해 구조적인 변동이 발생했을 때 값이 제대로 저장되지 않는 경우가 발생한다. 보통 Collection.synchronizeSet()와 같이 "wrap" 해주면 된다.

TL;DR

• non-dulplicate
• unordered
• null은 하나만 허용
• HashSet은 HashMap에 기반

references:

https://www.baeldung.com/java-hashset

https://docs.oracle.com/javase/8/docs/api/java/util/HashSet.html

https://docs.oracle.com/javase/8/docs/api/java/util/Set.html

신용권, 『이것이 자바다』, 한빛미디어

List collection을 구현하는 대표적인 클래스. AbstractList 추상 클래스를 상속하고, List를 비롯한 다른 세 interface를 구현한다. 나머지 interface에 대해서는 차차 다루도록 한다.

public class ArrayList 
    extends AbstractList
    implements List, Cloneable, Serialization, RandomAccess

특징

동적 array

List의 기능을 모두 구현하며, 마찬가지로 null과 객체를 상관 없이 저장할 수 있다. 또한 List 를 구현하는 다른 클래스를 ArrayList에 추가할 수도 있다. 동적 array로써 크기를 자유롭게 변경할 수 있다.

ArrayList도 List와 같이 zero-indexed array이며, index를 지정하지 않고 객체를 추가하면 순차적으로 index가 증가한다. 반면 특정 index에서 제거 또는 저장을 수행하면 바로 뒤 index부터 마지막 index까지 모두 앞으로 한 칸 움직여서 다시 정렬한다.

데이터 저장과 삭제 시에 모든 index를 재정렬하므로 이런 작업이 빈번한 곳에서는 ArrayList를 쓰기보다 LinkedList나 HashMap 등을 사용하는 것이 성능 면에서 좋을 수 있다. 하지만 index를 통해 객체에 접근하거나, 마지막 index에 순차적으로 삽입하는 단순 작업이라면 ArrayList를 쓰는 것이 무난할 것이다. 이는 뒤에 설명할 time complexity를 보면 좀 더 자세히 알 수있다.

capacity와 doubling, time complexity

ArrayList의 기본 capacity는 10으로, 항상 실제 list size보다 크게 설정되어 있다. index가 늘어남에 따라 자동으로 capacity가 doubling, 두 배로 늘어난다. 그리고 doubling 할 때 배열의 크기를 두 배 늘리고, list 내에 있는 값들을 모두 복사하여 옮긴다.

따라서 Capacity가 여유 있을 때 add()를 수행할 경우 time complexity는 O(1)이지만, capacity에 도달하여 doubling 될 때는 값들을 모두 복사하여야 하여야 하므로 값의 개수만큼(n)의 time complexity를 가지게 되어 O(n) worst case가 된다. 하지만 doubling 되는 경우가 단순 저장보다 빈번하지 않기 때문에 O(1)의 성능을 O(n)으로 평가해버리면 불합리할 수 있다. 이럴 때 amortized O(1)이라는 표현을 써서 doubling이 되지 않을 조건일 때 O(1)의 time complexity를 가진다는 것을 표현한다. (이 부분은 내가 알고리즘을 자세히 공부하지 않아서 디테일하게는 모르지만, 정리하여 얻은 부분이다. 기회가 된다면 time complexity와 space complexity에 대해서 공부해봐야겠다.).

get()의 경우 하나의 index에서만 값을 얻어오므로 항상 O(1)의 time complexity를 가진다.

메서드들의 time complexity를 정리해보면 다음과 같다.

• add : amortized O(1). O(n) worst case.
• add(idx, obj): O(n). 지정한 index 뒤로 한 칸씩 밀려나야 하므로 그렇다.
• get: O(1)
• remove, contain, indexOf: linear search 이므로, O(n) (앞 index부터 순차적 으로 iteration)

iteration

Iterable interface를 구현하므로 이를 통해 iteration할 수 있지만, List collection에서는 ListIterator를 제공한다. ListIterator는 bidirectional search를 수행하게 해주며, 이를 통해 List를 구현하는 클래스가 특정 index에서 객체를 저장하거나 삭제할 수 있도록 한다.

List<Integer> list = new ArrayList<Integer>();
    for(int i = 0 ; i<10;i++) {
        list.add(i);

    }
    ListIterator<Integer> it = list.listIterator(list.size());
    List<Integer> result = new ArrayList<Integer>(list.size());

    while(it.hasPrevious()) { // last index부터 검색가능
        result.add(it.previous());
    }

    Collections.reverse(result); // order reverse
    System.out.println(list.equals(result)); // true

또 하나 알 수 있는 점은 List의 경우 index와 저장된 값이 일치하는 두 List의 경우 equals() 수행 시 true를 반환한다는 것이다.

TL;DR

• ArrayList는 List collection의 대표적인 구현 클래스.
• Dynamic array로 크기를 바꿀 수 있음
• get(), add()의 경우 O(1)의 time complexity. 따라서 단순 검색, 마지막 index에 순차적 저장의 경우 성능이 괜찮음.
• 특정 index에 값을 저장, 삭제할 경우 요소를 재배열하게 되어 비효율적일 수 있음(LinkedList가 대안)
• linear search 이므로 remove(), contain(), indexOf()의 경우 O(n).

references : https://docs.oracle.com/javase/8/docs/api/java/util/List.html https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html https://www.baeldung.com/java-arraylist

time complexity https://medium.com/@satorusasozaki/amortized-time-in-the-time-complexity-of-an-algorithm-6dd9a5d38045 https://zeddios.tistory.com/60

List collection은 ordered collection이다. 삽입된 요소마다 index를 순차적으로 부여하며, 이 index를 통해 요소가 관리된다.

후에 알아볼 또 다른 collection인 Set과의 가장 큰 차이점은, List는 null을 허용한다는 점이다. 또한 null 또는 중복된 요소가 삽입될 수도 있다.

배열과 같이 zero-indexed 이다. 알아둘만한 점은 크기가 정해진 배열과 달리 값이 저장될 때 자동으로 capacity가 증가한다.

List 구현체에서 linear search를 하도록 설계되어 있는 경우가 많기 때문에 iteration을 수행할 때는 이런 점을 고려해서 수행해야 한다.

가장 대표적인 List 구현체로는 ArrayList와 Vector, LinkedList가 있다.

TL;DR

1. 순서를 가지는 collection
2. index를 통해 요소가 관리됨
3. null 허용, duplicate 허용
4. linear search의 경우가 많음 (iteration performance 고려)
   
   

*reference: * https://docs.oracle.com/javase/8/docs/api/java/util/List.html

Map 을 구현하는 대표적인 클래스.

Key를 저장할 때 hash function을 사용하므로 HashMap이라 한다. Value가 저장될 때 key 값이 hashing 처리되고, 처리된 hash code가 compressed되어 index를 생성한다. 해당 index에 entry가 저장된다. 특징을 정리해보면 다음과 같다.

특징

• Map의 성질을 가지고 있으므로 Key, Value pair의 구조를 가지고 있는 Entry 클래스로 데이터를 관리한다.
  
• Key 는 반드시 객체여야 한다. 데이터를 저장하고 데이터에 접근할 때, Object의 hashCode()와 equals()를 통해 Key가 일치하는지 확인하기 때문이다. 기본자료형으로 Key를 지정하면 Wrapper class에 의해 boxing 된다.
  
• 논리적으로 같은 키의 값이 중복으로 입력되면, 마지막으로 입력된 키와 paring된 값으로 업데이트 된다. 즉 중복 키가 허용되지 않는다.
  
• Key와 Value 에 null이 참조될 수 있다. 하지만 필요하지 않은 경우 지양해야 할 것이다.
  
• 배열 기반의 Map이다. 데이터를 검색할 때 hash로 접근하므로 단순 저장/검색으로 계산했을 때 평균 O(1)의 time complexity를 가진다. 따라서 저장된 데이터에 순차적으로 접근하여 검색하는 ArrayList보다 검색 속도가 빠르다. 검색하고자 하는 데이터가 정렬되어 있다면 O(n), binary search를 한다면 O(log n)까지 성능이 올라갈 수 있다. HashMap의 가장 큰 특징이라고 할 수 있다.
  
• 하지만 각 entry의 입력 순서를 기억하지 않으므로 데이터가 입력되는 순서가 중요하다면 LinkedHashMap을 사용하는 것이 선택지가 될 수 있다.
  
• 내부적으로 동기화가 되지 않기 때문에 multi thread 환경에서 HashMap에 대한 구조적인 변경(value 변경이 아닌 add나 delete, remove과 같이 entry를 조정하는 등의 변경)을 대비해 반드시 외부적으로 동기화를 선언해주거나, Collections.synchronizedMap(new HashMap()); 과 같이 동기화 설정을 해주는 것이 좋다. (동기화에 대해서는 개념만 알고 있기 때문에 지금은 이 정도로만 써둔다)
  

TL;DR

1. Hashing function을 사용하는 Map이다.
2. 단순 데이터 탐색, iteration을 할 경우 ArrayList보다 훨씬 빠르다.
3. Key 중복이 안된다.

HashMap을 이루고 있는 개념

HashMap을 비롯한 Map 컬렉션을 구현하는 클래스들은 대부분 아래와 같은 개념으로 이루어져 있다.

Bucket

HashMap은 앞서 말한 것처럼 배열 기반의 Map이며, 각 array 내의 node를 bucket이라고 한다. entry, 저장된 요소를 bucket이라고 보면 되겠다.

Capacity

저장할 수 있는 bucket 의 수. HashMap의 용량 정도라고 생각하면 되겠다. HashMap은 기본 생성자로 생성할 경우 기본 capacity가 16이다. HashMap을 생성할 때에 생성자의 인자로 capacity를 설정해줄 수 있다

Threshold

역치. HashMap에 저장 공간이 커져야 되는 시점이다. load factor * capacity로 계산할 수 있다. load factor는 언제 값이 늘어나야 하는지 정해주는 단위이다. 기본 설정은 0.75f 로, 이는 capacity의 75%를 말한다.
예를 들어 기본 생성자로 HashMap을 생성했다고 하면, capacity는 16, load factor는 0.75f로 설정되어 있어, threshold는 16 * 0.75 = 12 이다. 즉 해당 HashMap은 16개의 entry를 저장할 수 있으며, map의 size가 12개에 도달했을 때 HashMap의 크기가 커지게 된다. 크기는 두 배 가까이로 커지게 된다. 따라서 16이었던 크기는 32로 커지게 된다.

Rehashing

HashMap이 threshold에 도달해 크기가 커질 때 내부적으로 모든 bucket에 대해 rehashing이 발생한다. 구조적인 변경이 발생한다는 의미이다. load factor를 낮게 설정해서 complexity를 낮출 수는 있지만, 그만큼 rehashing이 자주 일어날 수 있다. rehashing 자체가 자원 소모가 큰 편이므로 HashMap에 저장될 데이터가 예측 가능하다면 capacity를 적절히 높이 설정하여 이런 문제를 어느 정도 해결 할 수 있겠다.

HashMap methods, constructor

constructor

생성자는 기본 생성자와 더불어 위에서 언급한 capacity, load factor를 파라미터로 하는 생성자와, Map 구현 클래스를 파라미터로 받는 생성자가 있다.

HashMap<String, String> bandNameAndCountry = new HashMap<>;
bandName.put("radiohead", "Britain");
bandName.put("interpol", "America");

HashMap<String, String> bandNameAndCountry2 = new HashMap<>(bandNameAndCountry);

System.out.println(bandNameAndCountry.equals(bandNameAndCountry2)); // true

method

Map의 메서드를 모두 구현하고 있다. put, get, remove, containValues 등을 모두 사용할 수 있다.

getOrDefault

JDK 1.8부터 추가된 기능. Key를 통해 값을 얻어오지만, Key 가 존재하지 않거나 Key에 매핑된 Vaule가 없는 경우 default 값을 지정해서 리턴시킬 수 있다.

HashMap<String, String> hashMap = new HashMap<>();
hashMap.put("hungry", "yes");
System.out.println(hashMap.getOrDefault("thirsty", "yeah")); // yeah

후술할 entrySet()과 keySet(), values() 등을 통해 HashMap을 iterate시킬 수 있다.

HashMap 기본 활용

HashMap의 entry를 다양한 방법으로 출력할 수 있다.

hashMap 예제

HashMap<String, String> hashMap = new HashMap<String, String>();
hashMap.put("food1", "hamburger");
hashMap.put("food2", "pizza");
hashMap.put("food3", "ramen");
hashMap.put("food4", "ramen");

entrySet()

Map의 entry를 Set view로 만든 뒤 iterate 시키는 방법이다.

for(Map.Entry<String, String> entries : hashMap.entrySet()) {
    System.out.println("key :"+ entries.getKey() + " value : "+entries.getValue()); 
}

//key :food1 value : hamburger
//key :food3 value : ramen
//key :food2 value : pizza
//key :food4 value : ramen

앞서 설명했듯 HashMap에서는 데이터의 저장 순서가 중요하지 않기 때문에, iterate 시켰을 때 순서가 다르게 나올 수도 있다.

keySet()

for(String s : hashMap.keySet()) {
    System.Out.println("key + "+s + " value : "+hashMap.get(s));
}

//key :food1 value : hamburger
//key :food3 value : ramen
//key :food2 value : pizza
//key :food4 value : ramen

Iterator 활용

Map을 iterate 시킬 때 사용하는 Iterator를 활용할 수 있다.

Iterator<Entry<String, String>> entries = hashMap.entrySet().iterator();

while(entries.hasNext()) {
    Entry<String, String> entry = entries.next();
    System.out.println(entry.getKey() + entry.getValue());
}

keySet() 를 통해 위 예제와 같이 get(key)로 iterate 시켜도 된다.

두 개의 HashMap 비교

두 개의 HashMap을 비교하고자 한다면 equals()를 통해 비교할 수 있다. 기본적으로 equals()가 객체에서 사용되었을 때에는 두 객체가 같은 인스턴스를 참조하고 있는지 확인하지만, HashMap에 equals()를 사용했을 때에는 두 개의 HashMap이 가지고 있는 entry들이 논리적으로 동등한지에 대해서만 확인한다. 앞에서 언급했듯 entry의 순서는 상관이 없다. 예를 들어서

HashMap<Integer, String> map1 = new HashMap<>();

map1.put(1, "A");
map1.put(2, "B");
map1.put(3, "C");

//Same as map1
HashMap<Integer, String> map2 = new HashMap<>();

map2.put(3, "C");
map2.put(1, "A");
map2.put(2, "B");

//Different from map1
HashMap<Integer, String> map3 = new HashMap<>();

map3.put(1, "A");
map3.put(2, "B");
map3.put(3, "C");
map3.put(3, "D");

System.out.println(map1.equals(map2));  //true
System.out.println(map1.equals(map3));  //false

위와 같을 경우 map1과 map2가 모두 new 키워드를 통해 생성된 객체이지만 equals() 비교 시 true가 리턴된다.

Key의 불변성 (immutability)

HashMap에서 POJO를 Key로 사용할 때에는 equals()와 hashCode()를 오버라이딩해서 논리적으로 동등한(객체의 데이터가 같은) 비교를 할 수 있도록 해야 한다. Key가 hashCode()의 값으로 저장되는데, 값을 가져올 때에 hashCode()로 bucket의 위치를 찾은 다음, 저장되어있는 hash code와 일치하는지 equals()로 판단한다. 따라서 hashCode()의 결과값이 같더라도 equals()에서 다른 값이라고 판단되면 다른 키로 인식하여 원하지 않는 결과가 나올 수 있다.

다음의 예를 보면

public class MutableKey{
    private String name;

    @Override
    public boolean equals(Object o){
        // 같은 인스턴스를 참조하고 있으면
        if(this == o){
            return true;
        }

        // 파라미터로 받은 객체가 null을 참조하거나 둘의 인스턴스가 다르면
        if(o == null || this.getClass() !=o.getClass()){
            return false;
        }

        MutableKey that = (MutableKey) o;

        //두 데이터의 값 일치를 비교해서 결과 리턴
        return Objects.equals(name, that.name);
    }

    @Override
    public int hashCode(){
        // name이 같을 경우 같은 hashcode 리턴
        return Objects.hash(name);
    }
}

이렇게 Key로 사용할 POJO 내에서 equals()와 hashCode()를 overriding 했을 경우, MutableKey 클래스의 name 필드를 따로 변경하지 않는 이상 HashMap의 키로 사용해도 항상 같은 hashcode를 리턴할 것이다.

HashMap<MutableKey, String> hashMap = new HashMap<MutableKey, String>();

hashMap.put(new MutableKey("name"), "John Doe");
String value = hashMap.get(new MutableKey("name"));
System.out.println(value); // John Doe

하지만 name field를 변경한 뒤 HashMap에서 값을 얻어오려고 하면, 변경된 변수에 대한 hash code를 가진 Key에 접근하려 하는 것과 같으므로 저장된 Value가 없어 null을 리턴하게 된다.

MutableKey key = new MutableKey("John Doe");

hashMap.put(key, "happy");
System.out.println(hashMap.get(key)); // happy

key.setName("punch");
System.out.println(hashMap.get(key)); // null

따라서 이런 점을 예상해서 코드를 짜거나, 되도록이면 immutable한 값을 키로 활용하는 것이 좋을 것 같다.

이번 포스트에서는 HashMap에 대해서 알아보았다.

references:

https://www.baeldung.com/java-hashmap-load-factor

https://www.baeldung.com/java-hashmap

https://d2.naver.com/helloworld/831311

https://stackoverflow.com/questions/55333952/is-there-an-array-based-map-implementation

https://stackoverflow.com/questions/37959941/what-exactly-is-bucket-in-hashmap

이전 포스트 (HTTP overview)에서 알아본 바와 같이, HTTP 기반의 웹 환경에서 요청과 응답의 데이터를 담고 있는 것이 HTTP message라고 하였다. 이번 포트스에서는 간단히 HTTP Message가 어떤 것인지 간단히 알아본다. 현재 HTTP/2가 등장했지만, 그 전에 HTTP message의 기본 구조를 알아보는 것이 목표이므로 HTTP/1을 중점으로 적는다.

HTTP Message는 ASCII로 인코딩된 요청과 응답의 데이터를 가지고 있다. 따라서 'HTTP Message = HTTP 요청/응답' 이라고 봐도 무방할 것 같다. 이 요청과 응답은 start-line*과 *header, body 세 가지로 구성되어 있다.

start-line

Chrome 같은 경우 개발자 도구 network에서 general 영역에 있는 항목과 같다. 크게 세 가지로 구분되어 있다.

• HTTP method : GET, POST, PUT, DELETE, PATCH 등 요청 시 사용된 method
• URL : 요청하고자 하는 자원의 위치. HTTP method에 따라 요청 시 생성되는 URL의 형태가 달라질 수 있다. 예를 들어 GET의 경우 파라미터가 query string의 형태로 URL에 포함되어 요청이 생성되기 때문에 "http://abc.org?param=value" 와 같이 '?' 뒤에 지정해놓은 파라미터가 key:value 형태로 넘어가게 된다.
  POST의 경우 query string으로도 파라미터를 넘길 수 있지만, form data인 body의 데이터를 전송하게 되므로 URL는 보통 "http://abc.org/post" 와 같이 작성하게 된다.
  
• status code: 응답의 start-line에 포함되어 있다. 요청을 수행한 결과에 따라 100 ~ 500번대로 나뉜다.
  
  - 100 : informational response. 한 번도 만나보지 못한 코드인데, 클라이언트의 추가작업이 필요하거나, 프로토콜의 변경 등이 필요할 때 발생한다고 한다.
  • 200 : successful response. 요청을 성공적으로 수행했을 때. 테스트까지 마치고 앱을 실행했을 때 나오면 뿌듯한 응답 상태.
  • 300 : redirection message. 요청한 URI의 자원이 변경되었거나 하는 경우 등장. POST의 경우 리소스를 만들어서 등록만 하는 method 이므로 redirection 해주지 않으면 302가 뜨는 것을 종종 볼 수 있다.
  • 400 : client errors. 유효하지 않은 URI나 method로 요청했을 경우 발생하는 상태. 오타이거나 파라미터를 추가 안했다거나 하는 단순한 실수가 많고 클라이언트 측 에러이므로 해결하기 비교적 쉽다.
  • 500 : server errors. 서버 측 문제. 개발을 연습하는 나의 입장으로는 500과 511을 종종 봤다. 500은 서버 내부 문제, 즉 Spring 쪽에서 코드를 잘 못 썼거나 예외 처리를 하지 않아서 runtime error가 난 경우이고, 511은 Spring security를 쓸 때 발생했었다.

Headers

해당 요청의 메타데이터들을 담긴 영역. 요청/응답의 주체 (요청의 경우 user-agent, host / 응답읭 경우 server)가 누구인지, 어떤 포맷으로 요청, 응답하는지 등에 대한 정보가 담겨 있다. 요청과 응답에 따라 조금 다르지만, 전반적인 구조는 같다.

request header

response header

서버 측에서는 header 정보를 읽어들여 이에 맞는 방식으로 데이터를 바인딩하거나 적절히 포맷된 데이터로 응답할 수 있다.

Body

요청/응답 마지막에 위치한 영역으로 payload의 영역과 같다. 다만 모든 요청/응답이 body를 가지고 있는 것은 아니다. 요청의 경우 GET 방식으로 자원의 URI만 요청한 경우에는 body가 없을 수 있다. 응답의 경우에도 마찬가지인데, POST 방식의 경우 리소스의 생성만 요청하므로 서버에서는 요청 수행 후 성공했다는 응답만 보여주면 된다. 그래서 보통 POST 수행 후에는 개발자가 임의로 redirect를 하는 방식으로 처리해준다.

Spring MVC를 통해 REST api를 구현할 때 @RequestBody나 @ResponseBody를 사용하는데 이 때 해당하는 부분이 이 HTTP body이다. 요청의 body를 받아들여서 바인딩하겠다는 것이거나 서버의 응답을 body로 하겠다는 의미이다.

*references: * https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

HTTP message에 대해 알아보다가, HTTP에 대해 기본적인 내용을 확실하게 정리해본 적이 없다는 것을 느꼈다. Mozilla doc을 참고해서, 내가 이해할 수 있는 방식으로 다시 정리해본다.

서버와 클라이언트 간의 통신을 위한 프로토콜. 해당 프로토콜을 통해 클라이언트는 원하는 자원을 요청할 수 있다. 응답 받은 자원(html, css, javascript)을 렌더링하고 각 uri에 해당하는 자원을 포함해 페이지를 재구축하는 작업은 웹 브라우저가 담당한다.

서버와 클라이언트 간의 상호작용은 HTTP message를 통해 이루어지며, 이 message를 요청이라고도 한다.

HTTP에 맞는 요청이 만들어지면 TCP통신을 통해 서버와 통신하고, 요청에 맞는 응답을 얻어온다. 어떤 통신 방식이든 상관없지만, HTTP는 TCP 통신에 기반하여 설계되었다. 뛰어난 확장성이 특장점으로, 자원을 얻어오는 것 뿐만 아니라 새로운 데이터를 저장하거나 기존 데이터를 수정할 수 있도록 서버에 요청하는 것도 가능하다. 이는 뒤에서 알아보겠지만, HTTP GET, POST, PUT, DELETE와 같은 메서드로 구현되어 있다.

HTTP components

거의 모든 요청은 일반적으로 클라이언트로부터 만들어진다. HTTP에 따라 만들어진 요청은 서버로 보내지고, 서버에서 MessageConverter 등을 통해 적절히 읽어들인 뒤 응답을 만들어 다시 클라이언트로 전송한다. HTTP response 는 종류에 따라 100 ~ 500 으로 나뉜다.

Client: the user-agent

요청을 생성하여 서버에 전송하는 주체이다. 서버에서 얻은 응답을 parsing하여 응답에 해당하는 web page를 렌더링하여 클라이언트에게 보여준다. 예를 들어 login 페이지를 클라이언트에서 요청했다면, 서버 쪽에 해당 페이지를 요청, 서버에서는 login.html의 위치를 응답에 담아 전송한다. 대표적인 클라이언트인 웹 브라우저에서는 서버로부터 받은 login.html을 불러와 렌더링하고, css나 js 같은 파일을 읽어들여 웹 페이지를 완성시켜 사용자에게 보여준다.

Web server

자원의 정보를 저장하고 있는 웹 서버이다. 하나 이상일 수 있고, 이전 포스트에서 다룬 것처럼 WAS도 포함될 수 있다. DB만을 저장하고 있는 서버, 캐시를 담당하는 웹 서버, load balancing을 위한 서벙 등 여러 서버가 있을 수 있지만, 클라이언트에 대해서는 하나의 서버처럼 동작한다.

proxies

아직 내가 다뤄보지 않아 확실히는 모르는 부분이지만, 곧 배우거나 알아야 할 부분이라 정리한다. 간단히 말해 서버와 클라이언트 사이에 관여하는 모든 entity를 proxy라고 한다. authentication entity, cache 를 관리하는 entity 등 다양한 proxy가 있으며, 클라이언트 서버 간 통신의 성능에 영향을 미칠 수 있다.

대부분 proxy는 전송, 네트워크 단계에서 수행되는 경우가 많으며, 서버로 보내는 요청을 추가로 가공한다든지, 요청을 포워딩한다든지 다양한 역할을 한다. doc에서는 HTTP message를 relay 한다는 표현을 썼는데, 그림에서 보는 것처럼 message를 각 entity에서 entity로 넘기는 것을 알 수 있다.

proxy는 아래와 같은 역할을 수행할 수 있다:

• caching (브라우저 캐시와 비슷함)
• filtering
• load balancing (다른 서버들을 함께 사용하기 위해)
• authentication (자원에 대한 접근 제한)
• logging (통신 간 history 제공)

Aspects of HTTP

HTTP is simple

human readable. 표준화되어 있고 읽기 쉬운구조로 되어 있다. header와 body로 되어 있고 각 정보들의 표현 방식은 accept, contentType 이런 식으로 되어 있어서 의미 파악이 쉽다.

HTTP is extensible

header를 수정/가공하기 편하기 때문에 테스트하기 편하다.

HTTP is stateless, but not sessionless

요청-응답 통신은 한 번 수행되고, 각 연결은 통신이 만들어 진 뒤 유지되지 않는다. 어떤 페이지를 요청해서 불러왔다고 하더라도 해당 페이지를 새로고침한다면 다시 요청을 수행하여 응답을 받아온다. 이를 무상태성, stateless라고 한다. 통신의 효율을 높이기 위해서인데, 쇼핑과 같이 유저가 선택한 목록을 유지하여야 하는 등의 경우 불편함이 발생한다. 이를 해결하기 위해 쿠키와 세션이 존재한다. 쿠키 세션 모두 상태 관리를 위한 조그마한 데이터인데, 쿠키는 브라우저에, 세션은 서버에 저장되고 관리된다. 기본적으로 쿠키는 서버 쪽에서 같은 클라이언트에서 온 요청인지 확인하기 위해 사용된다. 세션은 같은 쿠키를 가지고 요청한 클라이언트에 대해 저장소(세션)를 만들어 같은 쿠키를 가진 요청이 왔을 때 세션에 접근할 수 있도록 한다.

HTTP and connection

웹에서의 통신은 transport layer에서 수행되므로 HTTP layer과는 별도의 분야이다. HTTP는 어떤 통신 환경이든 작동하지만, message가 소멸되지 않는(최소한 에러가 발생했을 때 message가 표시될 수 있는) reliable한 환경을 요구하므로 TCP 통신 방식에 의존적이다.

What can be controlled by HTTP

앞서 살펴본 바와 비슷하게, HTTP를 통해 주로 컨트롤하는 부분은 아래와 같다.

• Caching: Cache에 대한 관리 -어떤 데이터를 얼마 동안 관리할 것인지 등-를 HTTP를 통해 할 수 있다.

• Authentication: HTTP에서 제공하는 header를 사용하거나, 특정 HTTP-Cookie를 설정함으로써 접근 제한을 구현할 수 있다.

• Proxies and tunneling: IP가 숨겨져 있거나 인트라넷과 같이 외부에서 접근이 제한되어 있는 곳으로부터 요청이 올 때, HTTP는 해당 요청이 오기까지의 proxy를 찾아 요청을 수행한다. 하지만 모든 proxy가 HTTP proxy가 아닌 경우도 있어 다른 프로토콜의 proxy인 경우 해당 프로토콜을 사용해야할 수도 있다. 이 부분은 잘 모르는 부분이지만 일단 체크해둔다.

• Session 서버는 Cookie를 통해 세션을 생성하고, 같은 클라이언트에서 온 Cookie인 경우 지정한 세션에 접근을 허용한다.

  
  ## HTTP flow 클라이언트가 요청을 보낼 때, 먼저 TCP 커넥션을 만들고, header와 body를 포함한 HTTP message를 만들어 서버로 보낸다.

GET / HTTP/1.1 Host: developer.mozilla.org Accept-Language: fr

해당 정보를 통해 서버에서 어떤 자원을 어떤 방식으로 읽어들이고 응답해야 하는지 알 수 있다. REST 방식으로 api를 작성할 때 JSON format으로 데이터를 통신하므로 보통 accept: application/json을 많이 쓰는데, 이를 통해 Spring에서는 MessageConverter를 통해 요청이 온 message가 json format인 걸 알 수 있다.

위와 같은 요청에 해당하는 자원이 있을 경우, 서버에서 응답이 만들어지고 클라이언트로 전송된다.

HTTP/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: "51142bc1-7449-479b075b2891b" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text/html

혼자 프로젝트를 개발하면서, 201, 415, 400 등 다양한 response status를 보았다. 응답에 대한 내용은 차차 다루도록 한다.

TL;DR 😒

• HTTP 는 클라이언트-서버 간 통신 규약이다.
• HTTP 는 stateless이며, human-readable하며, extensible하다
• HTTP component : client, server, and proxy
• proxy 는 client와 server 사이에서 HTTP message 를 전달하는 과정에 관여하는 모든 entity를 말한다.
• HTTP를 통해 session, caching, authentication 등의 기능을 관리할 수 있다.
  
  

references : https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview

자바에서 개발한 웹 애플리케이션 프로그램

Servlet; Server Applet

자바 언어로 동작하는 server-side 프로그램이다. 즉 확장자가.java 이다. front endpoint에서 요청을 받으면, 해당 uri에 매핑된 Serlvet이 서버에 접근하여 요청을 수행하고, 동작 결과를 동적으로 생성하여 클라이언트로 응답한다.

Servlet으로 선언하고 싶은 클래스를 HttpServlet 또는 GenericServlet 클래스를 상속하거나 해당 부모 클래스가 구현하고 있는 최상위 인터페이스인 Servlet 인터페이스를 구현하여 사용한다. (Servlet의 컨테이너 생성과 요청, 응답 객체에 대한 내용도 있는데, 이는 다른 포스팅에서 다루도록 한다)

Servlet만을 통해 개발하는 방식을 Model 1이라고도 한다. 내가 느낀 이 개발방법의 가장 큰 단점은, 요청과 Servlet의 매핑이 1대1로만 가능하기 때문에 요청 개수만큼 Servlet도 생성하여야 한다는 점이다. 예를 들어 상품 목록 화면이 있을 때 상품 목록 호출, 등록, 수정, 세부 내용 등 모든 기능에 대해 Servlet이 각각 필요하다. 이런 과정에서 불필요하게 중복되는 코드들이 발생한다.

JSP; Jarkarta Server Page

• scriptlet: <% %> 안에 자바코드 사용
• declaration tag : <%@ %> 선언문. 필드 선언
• expression tag : <%= %> 표현식. 코드 실행 후 리턴 등을 출력

Servlet과 JSP의 차이점

*references * : https://www.upgrad.com/blog/jsp-vs-servlet/

• Web server는 static한 자원을 주로 관리한다. 지정한 uri에 저장되어 있는 html 문서, 이미지, 비디오, 파일과 같은 자원들이다.

• WAS는 static, dynamic 자원을 모두 관리한다. 비즈니스 로직이라 불리는 클라이언트와 서버 간의 상호 작용, 트랜잭션의 결과를 동적으로 생성하여 응답한다.

  
  

WAS는 middleware라고도 할 수 있는데 이는 클라이언트와 서버 간의 중간 소프트웨어 역할을 하기 때문이다. WAS가 없던 웹 초기에는 클라이언트의 요청이 있을 때마다 JDBC 드라이버를 통해 서버에 접속하고 쿼리를 수행하고 접속을 닫아야 했으므로 자원의 낭비가 심했다. WAS를 통해 커넥션 풀과 같은 기술이 도입되면서 이런 비효율을 낮출 수 있었다.

대표적인 WAS

references : https://www.ibm.com/cloud/learn/web-server-vs-application-server

SELECT m.no, m.name, m.profileImage, 
    p.no, p.name, p.price
FROM member m, product p
WHERE m.no = {no}

Good practice of sql

Avoid using Asterik(*)

Table alias

ANSI SQL style

SELECT m.no, m.name, m.profileImage,
    p.no, p.name, p.price
FROM member m, 
JOIN product p 
ON m.no = p.no
WHERE m.no = {no}

source: https://www.w3schools.com/sql/sql_join.asp

JOIN과 ON 절을 쓸 때 알아 두어야 할 점은 아래 링크에 설명이 잘 되어있다. 간략히 정리하면 where의 경우 join이 끝난 후에 마지막에 필터링을 하고, on의 경우 join 이전에 하기 필터링을 한다는 점이다.

sql join where vs. on - Stackoverflow

EXISTS, NOT EXISTS than IN, NOT IN

references

https://www.dpriver.com/blog/2011/09/27/a-list-of-sql-best-practices/ https://codingsight.com/sql-query-optimization-tips/

Front endopint

getMyRcps : function(){

        const myRcpsTmpl = _.template($("#myRcpsTmpl").html());
        const $myRcpsUl = $(".mypage_myrecipe_tab.tab_wrap ul");

        $.ajax({
            url: '/mypage/ajax/myrecipes',
            type: 'GET',
            dataType:'json',
            error: function(){ alert('something went wrong')},
            success: function(json){
                console.log(json);
                $myRcpsUl.html(myRcpsTmpl({myRcps:json}));
            }

        });
    }

Api controller

@Slf4j
@RequiredArgsConstructor
@RestController
public class MypageApiController {

    private final RecipesService recipesService; 

    @GetMapping("/mypage/ajax/myrecipes")
    public List<Rcp> getMyRecipes(@LoginUser SessionUser user) {

        if(user!=null) {
            int memberNo = user.getNo();

            return recipesService.getRecipesByMemberNo(memberNo);
        }

        return null;

    }

SessionUser

@Getter
public class SessionUser {

    private int no, addressNo;
    private String email, name, nickname, profileImg;
    private char marketkeeperStep;

    @Builder
    public SessionUser(int no, int addressNo, String email, String name, String nickname, String profileImg, char marketkeeperStep) {
        super();
        this.no = no;
        this.addressNo = addressNo;
        this.email = email;
        this.name = name;
        this.nickname = nickname;
        this.profileImg = profileImg;
        this.marketkeeperStep = marketkeeperStep;
    }

}

문제 : BindException, ConversionFailedException

@Configuration
@Import(MvcTestConfig.class)
@EnableTransactionManagement
@ComponentScan(basePackages = {"com.ktx.ddep.controller","com.ktx.ddep.service", "com.ktx.ddep.argumentresolver"})
public class ApiTestConfig {

    @Bean
    public PasswordEncoder encoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public HttpSession sessionCreator() {
        return new MockHttpSession();
    }

}

MvcTestConfig

@Configuration
public class MvcTestConfig implements WebMvcConfigurer{

    private LoginUserArgResolver loginUserArgResolver;

    // enable default servlet when requests other than that made for spring is made
        @Override
        public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
            configurer.enable();
        }

        // jsp view resolver
        @Override
        public void configureViewResolvers(ViewResolverRegistry registry) {
            registry.jsp("/WEB-INF/view/", ".jsp");
        }

        // redirect request "/" to "/main"
        @Override
        public void addViewControllers(ViewControllerRegistry registry) {
            registry.addRedirectViewController("/", "/main");
        }

        @Override
        public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
            resolvers.add(loginUserArgResolver);
        }
}

MypageApiControllerTest.java

@RunWith(SpringRunner.class)
@ContextConfiguration(classes = {ApiTestConfig.class})
@Transactional
public class MypageApiControllerTest {

    // mock 객체를 생성하고 해당 mock 객체에 Mock으로 설정한 객체들을 주입
    @InjectMocks
    private MypageApiController apiController;

    @Mock
    private RecipesService rcpService;

    @Mock
    private List<Rcp> rcpList;

    private MockMvc mockMvc;

    @Before
    public void instantiate() {
        MockitoAnnotations.openMocks(this);
        mockMvc = MockMvcBuilders.standaloneSetup(apiController).build();    
        }

    @Test
    public void givenUser_whenGetRequest_thenIsStatusOk() throws Exception {

        //given
        SessionUser user = SessionUser.builder()
                .no(8)
                .addressNo(8)
                .email("wlgypark@gmail.com")
                .name("박지효")
                .nickname("짜릿한슬라임")
                .marketkeeperStep('i')
                .profileImg("profile.jpg")
                .build();

        //when
        when(apiController.getMyRecipes(user)).thenReturn(rcpList);

        //then
        mockMvc.perform(get("/mypage/ajax/myrecipes")).andExpect(status().isOk()).andDo(print());


    }

}

HttpMessageNotWritableException: nested Exception - jackson.databind.JsonMappingException: cannot invoke 'java.util.Iterator.hasNext()" because it is null

위와 같은 예외가 발생하며 테스트가 실패했다.

따라서 위와 같이 임의의 값을 담은 SessionUser 객체를 생성한 뒤 get 요청을 다시 수행하는 코드를 짠 뒤 테스트를 실행했다. 그러자

[org.springframework.validation.BindException: org.springframework.validation.BeanPropertyBindingResult] Field error in object 'sessionUser' on field 'no': rejected value [null]; [typeMismatch.sessionUser.no,typeMismatch.no,typeMismatch.int,typeMismatch]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [sessionUser.no,no]; arguments []; default message [no]]; default message [Failed to convert value of type 'null' to required type 'int'; nested exception is org.springframework.core.convert.ConversionFailedException: Failed to convert from type [null] to type [int] for value 'null'; nested exception is java.lang.IllegalArgumentException: A null value cannot be assigned to a primitive type]

해결 : no arg constructor

컨트롤러 메서드는 요청의 Accept와 Content-type이 포함된 header를 읽어들여 요청 정보의 미디어 타입을 확인하고, 이어 HttpMessageConverters를 통해 해당 미디어 타입을 핸들링할 수 있는 컨버터를 찾게 된다. 그리고 이 컨버터는 자바 엔티티를 클라이언트가 요청한 포맷으로 가공해주는 역할을 한다. 나는 @RestController를 사용할 계획이었으므로 json/xml로 응답하여야 했고, 컨버터로 jackson-databind 라이브러리를 사용했다.

During deserialization, the fields of non-serializable classes will be initialized using the public or protected no-arg constructor of the class. _A no-arg constructor must be accessible to the subclass that is serializable. _The fields of serializable subclasses will be restored from the stream.

references:

• https://www.baeldung.com/spring-httpmessageconverter-rest
• https://www.baeldung.com/java-serialization
• https://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html
• https://wondongho.tistory.com/76