ExecutorService는 이미 진행중인 작업을 모두 완료한 다음 종료할 수 있도록 Graceful Shutdown을 아래 메소드로 지원한다.

유관 메소드

shutdown()

void shutdown();

• 새로운 작업을 받지 않고, 이미 요청돤 작업을 모두 완료한 후 종료
• Non-Blocking으로 동작
  

shutdownNow()

List<Runnable> shutdownNow();

• 실행 중인 작업 중단 및 대기 중인 작업 반환 후 즉시 종료
• 실행 중인 작업을 중단하기 위해 인터럽트 발생
• Non-Blocking으로 동작
  

isShutdown()

boolean isShutdown();

• 서비스 종료 여부 확인
  

isTerminated()

boolean isTerminated();

• shutdown(), shutdownNow() 호출 후 모든 작업이 완료되었는지 확인
  

awaitTermination(long timeout, TimeUnit unit)

boolean awaitTermination(long timeout, TimeUnit unit) throws InterruptedException;

• 서비스 종료 시 모든 작업이 완료되기를 지정된 시간동안 대기
• Blocking 방식으로 동작
  

close()

    @Override
    default void close() {
        boolean terminated = isTerminated();
        if (!terminated) {
            shutdown();
            boolean interrupted = false;
            while (!terminated) {
                try {
                    terminated = awaitTermination(1L, TimeUnit.DAYS);
                } catch (InterruptedException e) {
                    if (!interrupted) {
                        shutdownNow();
                        interrupted = true;
                    }
                }
            }
            if (interrupted) {
                Thread.currentThread().interrupt();
            }
        }
    }

• shutdown() 호출 후 작업 완료를 하루 동안 대기, 이후에도 완료되지 않으면 shutdownNow() 호출
• 호출한 Thread에 인터럽트가 발생한 경우에도 shutdownNow()가 호출됨
• JDK 19부터 지원
  

ThreadPool 관리 전략

Executors 클래스에서는 ThreadPool을 효과적으로 관리하기 위한 여러 전략들을 제공한다. 이를 사용하거나 직접 정의할 수 있는데, 아래에서 상세히 알아본다.

기본 제공

⭐newSingleThreadExecutor

    public static ExecutorService newSingleThreadExecutor() {
        return newSingleThreadExecutor(defaultThreadFactory());
    }

    public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) {
        return new AutoShutdownDelegatedExecutorService
            (new ThreadPoolExecutor(1, 1,
                                    0L, TimeUnit.MILLISECONDS,
                                    new LinkedBlockingQueue<Runnable>(),
                                    threadFactory));
    }

• 단일 Thread를 사용하는 전략
• 대기 큐의 크기는 무제한
• 작업 실행 중 장애로 인해 단일 스레드 종료 시 새로운 Thread가 생성됨
• 한 번에 두 개 이상의 작업이 활성화되지 않으며, 초과 Thread를 사용
• newFixedThreadPool(1)과 달리 초과 Thread를 사용하도록 재구성할 수 없음
  

newSingleThreadScheduledExecutor

    public static ScheduledExecutorService newSingleThreadScheduledExecutor() {
        return new DelegatedScheduledExecutorService
            (new ScheduledThreadPoolExecutor(1));
    }

    public static ScheduledExecutorService newSingleThreadScheduledExecutor(ThreadFactory threadFactory) {
        return new DelegatedScheduledExecutorService
            (new ScheduledThreadPoolExecutor(1, threadFactory));
    }

• 지정 시간동안 대기 후 실행하거나 주기적으로 실행하도록 명령 예약 가능한 단일 Thread를 사용하는 Executor
• 이외 특징은 newSingleThreadExecutor와 동일
  

newScheduledThreadPool

    public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
        return new ScheduledThreadPoolExecutor(corePoolSize);
    }

    public static ScheduledExecutorService newScheduledThreadPool(
            int corePoolSize, ThreadFactory threadFactory) {
        return new ScheduledThreadPoolExecutor(corePoolSize, threadFactory);
    }

• 지정 시간동안 대기 후 실행하거나 주기적으로 실행하도록 명령 예약 가능한 ThreadPool 생성
  

⭐newFixedThreadPool

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

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

• 고정된 수의 Thread를 재사용하는 ThreadPool 생성
• 모든 Thread가 활성 상태일 때 추가 작업 요청 시 Thread를 사용할 수 있을때까지 대기 큐에서 대기
• 명시적으로 종료하기 전까지 Thread 유지
• 고정된 수의 Thread를 사용하므로 시스템 자원 사용량 예측 가능
• 대기 큐의 크기는 무제한이므로 처리 속도보다 작업이 쌓이는 속도가 더 빠른 경우 문제 발생 가능
  

⭐newCachedThreadPool

    public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                      60L, TimeUnit.SECONDS,
                                      new SynchronousQueue<Runnable>());
    }

    public static ExecutorService newCachedThreadPool(ThreadFactory threadFactory) {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                      60L, TimeUnit.SECONDS,
                                      new SynchronousQueue<Runnable>(),
                                      threadFactory);
    }

• 필요에 따라 새 Thread를 생성하지만 이전에 생성된 Thread를 사용할 수 있을 때 재사용하는 ThreadPool 생성
• 일반적으로 수명이 짧은 비동기 작업을 많이 실행하는 프로그램의 성능 향상 가능
• 사용 가능한 기존 Thread가 없는 경우 새 Thread가 생성되어 ThreadPool에 추가되며, 60초동안 사용되지 않으면 Thread 종료 후 캐시에서 제거됨
• SynchronousQueue를 사용하여 별도 버퍼를 사용하지 않으며, 생산자가 소비자에게 직접 작업을 전달하고 반환하는 방식
• 매우 유연한 전략이지만 시스템의 자원을 제한 없이 사용할 수 있어 주의가 필요함
  

newThreadPerTaskExecutor

    public static ExecutorService newThreadPerTaskExecutor(ThreadFactory threadFactory) {
        return ThreadPerTaskExecutor.create(threadFactory);
    }

• 각 작업에 대해 새 Thread를 시작하는 Executor 생성
• 생성하는 Thread 수에 제한 없음
• Future에서 cancel(true) 호출 시 작업 실행 Thread 중단
• JDK 21부터 지원
  

newVirtualThreadPerTaskExecutor

    public static ExecutorService newVirtualThreadPerTaskExecutor() {
        ThreadFactory factory = Thread.ofVirtual().factory();
        return newThreadPerTaskExecutor(factory);
    }

• 각 작업에 대해 새 Virtual Thread를 시작하는 Executor 생성
• 생성하는 Thread 수에 제한 없음
• Virtual Thread를 생성하는 ThreadFactory를 사용하여 newThreadPerTaskExecutor()를 호출하는 방식
• JDK 21부터 지원
  

newWorkStealingPool

    public static ExecutorService newWorkStealingPool(int parallelism) {
        return new ForkJoinPool
            (parallelism,
             ForkJoinPool.defaultForkJoinWorkerThreadFactory,
             null, true);
    }

    public static ExecutorService newWorkStealingPool() {
        return new ForkJoinPool
            (Runtime.getRuntime().availableProcessors(),
             ForkJoinPool.defaultForkJoinWorkerThreadFactory,
             null, true);
    }

• 지정된 병렬 처리 수준을 지원하기 위해 충분한 Thread를 유지하는 ThreadPool 생성
  • 병렬 처리 수준은 작업 처리에 참여 중이거나 참여할 수 있는 최대 Thread 수에 해당
• 경합을 줄이기 위해 여러 개의 대기 큐 사용 가능
• 실제 Thread 수는 동적으로 증가/감소
• 요청된 작업의 실행 순서를 보장하지 않음
  
  

사용자 정의

ThreadPoolExecutor의 생성자를 통해 직접 수치를 조정하면서 Executor를 생성하는 방식이다. 적정 수치는 성능 테스트 등을 통해 검증할 수 있다.

    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
                              ... 중략 ...
    }

단, 1편에서 말한 것처럼 maximumPoolSize의 경우 workQueue가 모두 찬 상태에서 작업이 요청된 경우 maximumPoolSize까지 Thread가 생성된다는 의미이다. maximumPoolSize를 의도한대로 사용하기 위해서는 workQueue의 사이즈가 제한되어 있는지 확인하는 것이 좋다.

ThreadFactory

Executors에서 기본 제공되는 전략을 사용할 때 ThreadFactory를 지정하지 않는 경우 기본적으로 DefaultThreadFactory를 사용하도록 설정된다.

    public static ThreadFactory defaultThreadFactory() {
        return new DefaultThreadFactory();
    }

DefaultThreadFactory는 ThreadFactory 인터페이스를 구현하고 있다.

public interface ThreadFactory {

    Thread newThread(Runnable r);
}

상세 구현은 아래와 같다.

    private static class DefaultThreadFactory implements ThreadFactory {
        private static final AtomicInteger poolNumber = new AtomicInteger(1);
        private final ThreadGroup group;
        private final AtomicInteger threadNumber = new AtomicInteger(1);
        private final String namePrefix;

        DefaultThreadFactory() {
            @SuppressWarnings("removal")
            SecurityManager s = System.getSecurityManager();
            group = (s != null) ? s.getThreadGroup() :
                                  Thread.currentThread().getThreadGroup();
            namePrefix = "pool-" +
                          poolNumber.getAndIncrement() +
                         "-thread-";
        }

        public Thread newThread(Runnable r) {
            Thread t = new Thread(group, r,
                                  namePrefix + threadNumber.getAndIncrement(),
                                  0);
            if (t.isDaemon())
                t.setDaemon(false);
            if (t.getPriority() != Thread.NORM_PRIORITY)
                t.setPriority(Thread.NORM_PRIORITY);
            return t;
        }
    }

ThreadPoolExecutor 예외 정책

ThreadPoolExecutor의 생성자를 통해 대기 큐가 꽉 찼을 때 새로운 작업이 요청된 경우 처리 방안을 RejectedExecutionHandler를 통해 구현할 수 있다.

ThreadPoolExecutor에는 기본 핸들러로 AbortPolicy가 등록되어 있다.

private static final RejectedExecutionHandler defaultHandler = new AbortPolicy();

기본 제공

AbortPolicy

    public static class AbortPolicy implements RejectedExecutionHandler {

        public AbortPolicy() { }

        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
            throw new RejectedExecutionException("Task " + r.toString() +
                                                 " rejected from " +
                                                 e.toString());
        }
    }

• RejectedExecutionException 예외를 발생시켜 새로운 요청 거절
  

DiscardPolicy

    public static class DiscardPolicy implements RejectedExecutionHandler {

        public DiscardPolicy() { }

        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
        }
    }

• 새로운 작업 요청 시 무시

DiscardOldestPolicy

    public static class DiscardOldestPolicy implements RejectedExecutionHandler {

        public DiscardOldestPolicy() { }

        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
            if (!e.isShutdown()) {
                e.getQueue().poll();
                e.execute(r);
            }
        }
    }

• 새로운 작업 요청 시 가장 오래된 요청을 무시
• 다른 Thread가 작업이 종료되기를 기다리거나 작업 실패를 기록해야 하는 경우 유용하지 않음
  

CallerRunsPolicy

    public static class CallerRunsPolicy implements RejectedExecutionHandler {

        public CallerRunsPolicy() { }

        public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
            if (!e.isShutdown()) {
                r.run();
            }
        }
    }

• 새로운 작업을 요청한 Thread가 직접 작업 실행
  
  

사용자 정의

RejectedExecutionHandler를 직접 구현하여 필요한 기능을 구현한다.

public interface RejectedExecutionHandler {

    void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
}

참고 자료

• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/ExecutorService.html
• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/Executors.html

• 반환 값이 없음
• 체크 예외 throw 불가

Thread를 직접 다루게 되면..

아래 문제들을 겪게 된다.

1. Thread 생성 시간으로 인한 성능 문제
2. Thread 관리 필요
3. Runnable 인터페이스의 한계

이러한 문제들을 해결하기 위해 생성한 Thread를 재사용하는 자바에서는 java.util.concurrent 패키지를 통해 Executor 프레임워크를 제공한다.

이를 이용하면 매우 편리하게 Thread를 사용할 수 있게 된다.

Executor 프레임워크

개요

멀티 스레딩 및 병렬 처리를 쉽게 사용할 수 있도록 돕는 기능의 모음

주요 구성 요소

Executor

Runnable 작업을 제출하고 반환 값을 받지 않는 execute(Runnable command)가 정의되어 있다.

public interface Executor {

    void execute(Runnable command);
}

ExecutorService

Executor 인터페이스를 확장하여 작업 진행과 제어 기능을 추가로 제공한다.

public interface ExecutorService extends Executor, AutoCloseable {

    void shutdown();

    List<Runnable> shutdownNow();

    boolean isShutdown();

    boolean isTerminated();

    boolean awaitTermination(long timeout, TimeUnit unit) throws InterruptedException;

    <T> Future<T> submit(Callable<T> task);

    Future<?> submit(Runnable task);

    <T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks) throws InterruptedException;

    <T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks, long timeout, TimeUnit unit) throws InterruptedException;

    <T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionException;

    @Override
    default void close() {
        boolean terminated = isTerminated();
        if (!terminated) {
            shutdown();
            boolean interrupted = false;
            while (!terminated) {
                try {
                    terminated = awaitTermination(1L, TimeUnit.DAYS);
                } catch (InterruptedException e) {
                    if (!interrupted) {
                        shutdownNow();
                        interrupted = true;
                    }
                }
            }
            if (interrupted) {
                Thread.currentThread().interrupt();
            }
        }
    }
}

주요 메서드

<T> Future<T> submit(Callable<T> task)

• Callable 작업을 제출하고 결과를 반환 받음
  

Future<?> submit(Runnable task);

• Runnable 작업을 제출하고 결과를 반환 받음
• Runnable은 반환 값이 없어 리턴 받은 Future를 통해 get() 수행 시 null 반환
  

<T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks) throws InterruptedException;

• 모든 Callable 작업을 제출하고, 모든 작업이 완료될 때까지 대기
• 대기 시간을 지정하기 위해 long timeout, TimeUnit unit을 추가로 전달 받는 메서드도 오버로딩 되어 있음
  

<T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionException;

• 하나의 Callable 작업이 완료될 때까지 기다리고 가장 먼저 완료된 작업의 결과를 반환, 완료되지 않은 나머지 작업은 모두 취소
• 대기 시간을 지정하기 위해 long timeout, TimeUnit unit을 추가로 전달 받는 메서드도 오버로딩 되어 있음

ThreadPoolExecutor

ExecutorService 인터페이스의 대표적인 구현체다. 살펴보면 크게 Thread Pool과 BlockingQueue가 존재하며, 내부 클래스인 Worker를 정의 및 Runnable를 구현하여 멤버 변수로 가지고 있는 Thread의 작업을 수행하는 Worker로써 동작하도록 한다.

• Thread Pool : Thread 관리 (=workers)
• BlockingQueue : Thread가 처리할 작업 보관 (=workQueue)

생성자의 주요 매개변수로는 아래와 같다.

• corePoolSize : Thread Pool에서 관리되는 기본 스레드의 수
• maximumPoolSize : Thread Pool에서 관리되는 최대 스레드의 수
• keepAliveTime, TimeUnit unit : 기본 스레드를 초과하여 만들어진 Thread가 생존 가능한 대기 시간이며, 이 시간 동안 처리할 작업이 없다면 초과 스레드는 제거
• BlockingQueue : 작업을 보관할 블로킹 큐

public class ThreadPoolExecutor extends AbstractExecutorService {

    .. 중략 ..
    private final BlockingQueue<Runnable> workQueue;
    private final ReentrantLock mainLock = new ReentrantLock();
    private final HashSet<Worker> workers = new HashSet<>();
    private final Condition termination = mainLock.newCondition();
    private final SharedThreadContainer container;

    private int largestPoolSize;
    private long completedTaskCount;
    private volatile ThreadFactory threadFactory;
    private volatile RejectedExecutionHandler handler;
    private volatile long keepAliveTime;
    private volatile boolean allowCoreThreadTimeOut;
    private volatile int corePoolSize;
    private volatile int maximumPoolSize;
    private static final RejectedExecutionHandler defaultHandler = new AbortPolicy();

    private final class Worker extends AbstractQueuedSynchronizer implements Runnable 

        @SuppressWarnings("serial") // Unlikely to be serializable
        final Thread thread;

        @SuppressWarnings("serial") // Not statically typed as Serializable
        Runnable firstTask;

        volatile long completedTasks;

        Worker(Runnable firstTask) {
            setState(-1); // inhibit interrupts until runWorker
            this.firstTask = firstTask;
            this.thread = getThreadFactory().newThread(this);
        }

        public void run() {
            runWorker(this);
        }

        // Lock methods
        //
        // The value 0 represents the unlocked state.
        // The value 1 represents the locked state.

        protected boolean isHeldExclusively() {
            return getState() != 0;
        }

        protected boolean tryAcquire(int unused) {
            if (compareAndSetState(0, 1)) {
                setExclusiveOwnerThread(Thread.currentThread());
                return true;
            }
            return false;
        }

        protected boolean tryRelease(int unused) {
            setExclusiveOwnerThread(null);
            setState(0);
            return true;
        }

        public void lock()        { acquire(1); }
        public boolean tryLock()  { return tryAcquire(1); }
        public void unlock()      { release(1); }
        public boolean isLocked() { return isHeldExclusively(); }

        void interruptIfStarted() {
            Thread t;
            if (getState() >= 0 && (t = thread) != null && !t.isInterrupted()) {
                try {
                    t.interrupt();
                } catch (SecurityException ignore) {
                }
            }
        }
    }

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

    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
        if (corePoolSize < 0 ||
            maximumPoolSize <= 0 ||
            maximumPoolSize < corePoolSize ||
            keepAliveTime < 0)
            throw new IllegalArgumentException();
        if (workQueue == null || threadFactory == null || handler == null)
            throw new NullPointerException();
        this.corePoolSize = corePoolSize;
        this.maximumPoolSize = maximumPoolSize;
        this.workQueue = workQueue;
        this.keepAliveTime = unit.toNanos(keepAliveTime);
        this.threadFactory = threadFactory;
        this.handler = handler;

        String name = Objects.toIdentityString(this);
        this.container = SharedThreadContainer.create(name);
    }

    public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();

        int c = ctl.get();
        if (workerCountOf(c) < corePoolSize) {
            if (addWorker(command, true))
                return;
            c = ctl.get();
        }
        if (isRunning(c) && workQueue.offer(command)) {
            int recheck = ctl.get();
            if (! isRunning(recheck) && remove(command))
                reject(command);
            else if (workerCountOf(recheck) == 0)
                addWorker(null, false);
        }
        else if (!addWorker(command, false))
            reject(command);
    }
    .. 중략 ..
}

Thread Pool에 미리 지정한 수만큼 Thread를 생성하지 않으며, execute(Runnable command)를 통해 작업 시작 시 Worker의 수가 corePoolSize보다 적은 경우 Worker가 생성되도록 한다.

corePoolSize보다 많은 Worker가 수행되고 있지만, maximumPoolSize보다 적은 수의 Worker가 수행되고 있는 경우 아래와 같이 동작한다.

• Queue가 가득 차지 않은 경우: 즉시 실행하지 않고 Queue에 작업 추가
• Queue가 가득 찬 경우: maxPoolSize까지 Worker 생성하여 수행

Executors

ThreadPoolExecutor 객체 생성을 static 메서드로 아래와 같이 편리하게 사용할 수 있게 한다.

public class Executors {

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

    ... 중략 ...

Callable

Generic을 통해 원하는 타입의 값을 반환할 수 있으며, call() 메서드 선언에 예외가 선언되어 있어 Runnable의 한계를 극복할 수 있게 한다.

public interface Callable<V> {

    V call() throws Exception;
}

Future

resultNow(), exceptionNow(), state()의 경우 JDK 19 이상부터 사용 가능하다.

public interface Future<V> {

    boolean cancel(boolean mayInterruptIfRunning);

    boolean isCancelled();

    boolean isDone();

    V get() throws InterruptedException, ExecutionException;

    V get(long timeout, TimeUnit unit)
        throws InterruptedException, ExecutionException, TimeoutException;

    /**
     * @since 19
     */
    default V resultNow() {
        if (!isDone())
            throw new IllegalStateException("Task has not completed");
        boolean interrupted = false;
        try {
            while (true) {
                try {
                    return get();
                } catch (InterruptedException e) {
                    interrupted = true;
                } catch (ExecutionException e) {
                    throw new IllegalStateException("Task completed with exception");
                } catch (CancellationException e) {
                    throw new IllegalStateException("Task was cancelled");
                }
            }
        } finally {
            if (interrupted) Thread.currentThread().interrupt();
        }
    }

    /**
     * @since 19
     */
    default Throwable exceptionNow() {
        if (!isDone())
            throw new IllegalStateException("Task has not completed");
        if (isCancelled())
            throw new IllegalStateException("Task was cancelled");
        boolean interrupted = false;
        try {
            while (true) {
                try {
                    get();
                    throw new IllegalStateException("Task completed with a result");
                } catch (InterruptedException e) {
                    interrupted = true;
                } catch (ExecutionException e) {
                    return e.getCause();
                }
            }
        } finally {
            if (interrupted) Thread.currentThread().interrupt();
        }
    }

    /**
     * @since 19
     */
    enum State {
        /**
         * The task has not completed.
         */
        RUNNING,
        /**
         * The task completed with a result.
         * @see Future#resultNow()
         */
        SUCCESS,
        /**
         * The task completed with an exception.
         * @see Future#exceptionNow()
         */
        FAILED,
        /**
         * The task was cancelled.
         * @see #cancel(boolean)
         */
        CANCELLED
    }

    /**
     * @since 19
     */
    default State state() {
        if (!isDone())
            return State.RUNNING;
        if (isCancelled())
            return State.CANCELLED;
        boolean interrupted = false;
        try {
            while (true) {
                try {
                    get();  // may throw InterruptedException when done
                    return State.SUCCESS;
                } catch (InterruptedException e) {
                    interrupted = true;
                } catch (ExecutionException e) {
                    return State.FAILED;
                }
            }
        } finally {
            if (interrupted) Thread.currentThread().interrupt();
        }
    }
}

주요 메서드

boolean cancel(boolean mayInterruptIfRunning);

• 아직 완료되지 않은 작업을 취소
• mayInterruptIfRunning의 값에 따라 동작 상이
  • true : 취소 상태로 변경 후 작업이 실행중인 경우 인터럽트 발생시켜 중단
  • false : 취소 상태로 변경, 실행중인 작업 미중단
• 취소 상태의 Future의 get()을 호출하면 CancellationException 발생
  

boolean isCancelled();

• 취소 여부 리턴
  

boolean isDone();

• 작업 완료 여부 리턴 (완료/취소/예외 발생하여 중단된 경우 true)
  

V get() throws InterruptedException, ExecutionException;

• 작업이 완료될 때까지 대기 후 결과 값 반환
• 대기하는 과정에서 메서드 호출 Thread의 Blocking 발생
  

사용 예제

아래와 같이 Callable의 작업을 수행 요청하고, 값을 가져오는 데에 사용할 수 있다.

 interface ArchiveSearcher { 
     String search(String target); 
 }

 class App {

   ExecutorService executor = ...;
   ArchiveSearcher searcher = ...;

   void showSearch(String target) throws InterruptedException {
     Callable<String> task = () -> searcher.search(target);
     Future<String> future = executor.submit(task);
     displayOtherThings(); // do other things while searching
     try {
       displayText(future.get()); // use future
     } catch (ExecutionException ex) { cleanup(); return; }
   }
 }

FutureTask

Future의 대표적인 구현체로 RunnableFuture를 구현하며, 내부적으로 수행해야 할 작업과 상태 및 반환 값을 가지고 있다.

public class FutureTask<V> implements RunnableFuture<V> {

    private volatile int state;
    private static final int NEW          = 0;
    private static final int COMPLETING   = 1;
    private static final int NORMAL       = 2;
    private static final int EXCEPTIONAL  = 3;
    private static final int CANCELLED    = 4;
    private static final int INTERRUPTING = 5;
    private static final int INTERRUPTED  = 6;

    private Callable<V> callable;
    private Object outcome;
    private volatile Thread runner;
    private volatile WaitNode waiters;


    ... 중략 ...

    @SuppressWarnings("unchecked")
    private V report(int s) throws ExecutionException {
        Object x = outcome;
        if (s == NORMAL)
            return (V)x;
        if (s >= CANCELLED)
            throw new CancellationException();
        throw new ExecutionException((Throwable)x);
    }

    public V get() throws InterruptedException, ExecutionException {
        int s = state;
        if (s <= COMPLETING)
            s = awaitDone(false, 0L);
        return report(s);
    }

    private int awaitDone(boolean timed, long nanos) throws InterruptedException {
        WaitNode q = null;
        boolean queued = false;
        for (;;) {
            int s = state;
            if (s > COMPLETING) {
                if (q != null)
                    q.thread = null;
                return s;
            }
            else if (s == COMPLETING)
                Thread.yield();
            else if (Thread.interrupted()) {
                removeWaiter(q);
                throw new InterruptedException();
            }
            else if (q == null) {
                if (timed && nanos <= 0L)
                    return s;
                q = new WaitNode();
            }
            else if (!queued)
                queued = WAITERS.weakCompareAndSet(this, q.next = waiters, q);
            else if (timed) {
                final long parkNanos;
                if (startTime == 0L) { // first time
                    startTime = System.nanoTime();
                    if (startTime == 0L)
                        startTime = 1L;
                    parkNanos = nanos;
                } else {
                    long elapsed = System.nanoTime() - startTime;
                    if (elapsed >= nanos) {
                        removeWaiter(q);
                        return state;
                    }
                    parkNanos = nanos - elapsed;
                }
                if (state < COMPLETING)
                    LockSupport.parkNanos(this, parkNanos);
            }
            else
                LockSupport.park(this);
        }
    }
    ... 중략 ...
}

Future의 필요성

왜 ExecutorService에서 바로 반환 값을 받지 않고 Future의 get()을 통하여 반환 값을 받을까?

ExecutorService에서 작업 요청 후 결과 반환 시점까지 대기한다면 요청 Thread에서 Blocking이 발생하여 성능 저하 발생 가능하다. Future는 요청 스레드를 Blocking 상태로 만들지 않도록 하고, get() 호출 전까지 필요한 작업을 진행할 수 있도록 한다.

참고 자료

• JDK 21 공식 문서 (각 클래스/인터페이스명에 링크)
• https://leeyh0216.github.io/posts/truth_of_threadpoolexecutor/

2편에 계속...

java.util 패키지 내 컬렉션 프레임워크의 대부분은 thread-safe 하지 않다. 이러한 문제점을 자바에서는 어떻게 해결하였는지 살펴보자.

Vector와 synchronized

최초에 자바는 이러한 문제를 해결하기 위해 JDK 1.0에서 java.util 패키지에서 Vector 클래스를 지원하였다. 하지만 아래 코드와 같이 synchronized 를 통해 동기화를 구현하여 단일 스레드에서도 불필요한 성능 저하가 발생하게 되었고, 지금은 거의 사용되지 않게 되었다. 현재는 하위 호환을 위해 존재하나, 사용을 권장하지 않는다.

package java.util;

public class Vector<E>
    extends AbstractList<E>
    implements List<E>, RandomAccess, Cloneable, java.io.Serializable
{

    @SuppressWarnings("serial") // Conditionally serializable
    protected Object[] elementData;

    protected int elementCount;
    protected int capacityIncrement;

    ... 중략 ...


    public synchronized void copyInto(Object[] anArray) {
        System.arraycopy(elementData, 0, anArray, 0, elementCount);
    }

    public synchronized int capacity() {
        return elementData.length;
    }

    public synchronized int size() {
        return elementCount;
    }

    public synchronized boolean isEmpty() {
        return elementCount == 0;
    }

    public synchronized int indexOf(Object o, int index) {
        if (o == null) {
            for (int i = index ; i < elementCount ; i++)
                if (elementData[i]==null)
                    return i;
        } else {
            for (int i = index ; i < elementCount ; i++)
                if (o.equals(elementData[i]))
                    return i;
        }
        return -1;
    }

    ... 중략 ...
}

동시성 컬렉션

1) Collections.synchronizedXX()

프록시 패턴을 이용하여 Collection 타입 객체를 synchronized 블록 내에서 동작하도록 구현한 기능이다.

유관 메서드

synchronizedCollection()

public static <T> Collection<T> synchronizedCollection(Collection<T> c) {
    return new SynchronizedCollection<>(c);
}

synchronizedList()

public static <T> List<T> synchronizedList(List<T> list) {
    return (list instanceof RandomAccess ?
        new SynchronizedRandomAccessList<>(list) :
        new SynchronizedList<>(list));
}

synchronizedMap()

public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) {
    return new SynchronizedMap<>(m);
}

synchronizedSet()

public static <T> Set<T> synchronizedSet(Set<T> s) {
    return new SynchronizedSet<>(s);
}

synchronizedNavigableMap()

public static <K,V> NavigableMap<K,V> synchronizedNavigableMap(NavigableMap<K,V> m) {
    return new SynchronizedNavigableMap<>(m);
}

synchronizedNavigableSet()

public static <T> NavigableSet<T> synchronizedNavigableSet(NavigableSet<T> s) {
    return new SynchronizedNavigableSet<>(s);
}

synchronizedSortedMap()

public static <K,V> SortedMap<K,V> synchronizedSortedMap(SortedMap<K,V> m) {
    return new SynchronizedSortedMap<>(m);
}

synchronizedSortedSet()

public static <T> SortedSet<T> synchronizedSortedSet(SortedSet<T> s) {
    return new SynchronizedSortedSet<>(s);    
}

NavigableMap과 NavigableSet이란? 주어진 검색 대상에 가장 가까운 일치 항목을 반환하는 탐색 메서드를 제공하기 위해 SortedMap과 SortedSet을 확장하였으며, 각각 정렬된 맵과 집합을 지원한다.
두 인터페이스의 대표적인 구현체로는 TreeMap, TreeSet이 있다.

프록시 패턴 이용 방식

SynchronizedList를 예시로 살펴보자. 구현체 내부에 list 멤버변수를 두어 생성자로 넘겨 받은 List 객체로 설정한다.

이후 get(), set(), add(), remove()와 같은 동작에서 synchronized 블록 내에서 기존 객체의 동작을 수행하도록 구현되어 있다.

편리하게 이용 가능하지만 동기화 오버헤드로 인한 성능 저하, 동기화 최적화가 불가하다는 한계가 존재한다.

static class SynchronizedList<E> extends SynchronizedCollection<E> implements List<E> {

    @SuppressWarnings("serial") // Conditionally serializable
    final List<E> list;

    SynchronizedList(List<E> list) {
        super(list);
        this.list = list;
    }
    SynchronizedList(List<E> list, Object mutex) {
        super(list, mutex);
        this.list = list;
    }

    public boolean equals(Object o) {
        if (this == o)
            return true;
        synchronized (mutex) {return list.equals(o);}
    }
    public int hashCode() {
        synchronized (mutex) {return list.hashCode();}
    }

    public E get(int index) {
        synchronized (mutex) {return list.get(index);}
    }
    public E set(int index, E element) {
        synchronized (mutex) {return list.set(index, element);}
    }
    public void add(int index, E element) {
        synchronized (mutex) {list.add(index, element);}
    }
    public E remove(int index) {
        synchronized (mutex) {return list.remove(index);}
    }

    public int indexOf(Object o) {
        synchronized (mutex) {return list.indexOf(o);}
    }
    public int lastIndexOf(Object o) {
        synchronized (mutex) {return list.lastIndexOf(o);}
    }

    public boolean addAll(int index, Collection<? extends E> c) {
        synchronized (mutex) {return list.addAll(index, c);}
    }

    ... 중략 ...
}

2) java.util.concurrent

LinkedHashSet, LinkedHashMap과 같이 입력 순서를 유지하는 동시에 thread-safe한 Set, Map 구현체는 제공하지 않는다.

List

CopyOnWriteArrayList

• 모든 요소 변경과 관련된 연산(추가, 설정 등)이 기본 배열의 새 복사본을 만들어서 구현되는 ArrayList의 thread-safe한 버전
• 일반적으로 비용이 많이 들지만 순회 연산이 변경과 관련된 연산보다 훨씬 많은 경우 다른 대안보다 효율적
  

Set

CopyOnWriteArraySet

• 모든 연산에 내부 CopyOnWriteArrayList를 사용하는 Set
• 일반적으로 집합 크기가 작고, 읽기 전용 연산이 쓰기 연산보다 훨씬 많으며, 순회하는 동안 스레드 간 간섭을 방지해야 하는 애플리케이션에 가장 적합
• 요소 변경과 관련된 연산은 일반적으로 전체 기본 배열을 복사해야 하므로 비용이 많이 들어감

ConcurrentSkipListSet

• ConcurrentSkipListMap에 기반한 확장 가능한 동시 탐색 가능한 구현체
• 집합의 요소는 사용된 생성자에 따라 정렬된 상태로 유지 (Comparator 사용 가능)
  

Map

ConcurrentHashMap

• 검색의 완전한 동시성과 업데이트에 대한 높은 기대 동시성을 지원하는 해시 테이블
• 해시테이블과 동일한 기능을 제공하며, 해시테이블의 각 메서드에 대응하는 메서드 버전을 포함
• 모든 연산이 thread-safe 하지만 검색 연산에는 락을 사용하지 않으며, 모든 액세스를 방지하는 방식으로 전체 테이블을 잠그는 기능은 지원되지 않음

ConcurrentSkipListMap

• 확장 가능한 ConcurrentNavigableMap의 구현체
• 사용된 생성자에 따라 정렬된 상태로 유지 (Comparator 사용 가능)
  

Queue

ConcurrentLinkedQueue

• 연결된 노드를 기반으로 하는 thread-safe 큐
• 요소를 FIFO 방식으로 정렬 (큐의 헤드는 큐에 가장 오래 대기 중인 요소)
• 효율적인 Non-Blocking 알고리즘을 사용
  

Deque

ConcurrentLinkedDeque

• 연결된 노드를 기반으로 하는 thread-safe Deque
• 컬렉션의 비동기적 특성으로 인해 현재 요소 수를 확인하려면 요소를 순회해야 하므로 순회 중에 컬렉션이 수정되면 부정확한 결과가 리턴될 수 있음
• addAll(), removeIf() 또는 forEach()와 같이 여러 요소를 대량으로 추가, 제거 또는 조회하는 연산은 원자적으로 수행된다고 보장할 수 없음
  
  

참고 자료

• https://tech.socarcorp.kr/dev/2021/10/19/sub-interfaces-navigablemap.html
• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/NavigableMap.html

보통 동시성 이슈의 많은 원인은 값을 조회하고 값을 변경하는 과정이 원자적이지 않기 때문에 발생한다. 자바에서 이러한 연산의 원자성을 지원하기 위해 AtomicInteger와 같은 클래스를 지원한다.

연산의 원자성

해당 연산이 더 이상 나눌 수 없는 단위로 수행되는 경우 이를 원자적 연산이라 한다. i++과 같은 연산도 i = i + 1의 축약이므로 원자적인 연산은 아니다.

멀티 스레드를 사용하는 경우 원자적 연산은 문제가 되지 않아 대체적으로 문제가 되는 연산은 원자적이지 않은 연산이다.

CAS 연산

락을 사용하지 않고 원자적인 연산을 수행할 수 있게 하며, CAS(Compare-And-Swap, Compare-And-Set) 연산 또는 락 프리 기법이라고도 한다. 소프트웨어가 아닌 CPU 하드웨어에서 지원하는 기능이다.

동작 방식 예시

1. 현재 변경하고자 하는 값이 예상한 값과 동일한지 비교
2. 예상한 값과 동일한 경우 바꾸고자 하는 값으로 변경, 동일하지 않은 경우 변경하지 않음
   

주요 라이브러리

CAS 연산을 사용하는 자바 라이브러리 중 일부이다.

1. java.util.concurrent 패키지
   • 자바 표준 라이브러리에서 제공하는 라이브러리로, atomic 패키지 내 클래스들은 CAS 연산을 기반으로 동작한다.
   • 이외에 ForkJoinPool도 이 연산을 기반으로 동작한다.
2. Netty : 비동기 이벤트 기반 네트워크 애플리케이션 프레임워크
3. Reactor, RxJava : 비동기 스트림 처리에 사용되며 이벤트 기반 라이브러리
4. JCTools : 경량화된 동시성 도구 모음
5. Disruptor : 고성능 Non-Blocking 메시징 라이브러리로, CAS 연산 기반의 Ring Buffer를 사용한다.

Spring Webflux를 사용하게 되면 Reactor와 Netty를 접하게 되는데, 해당 라이브러리 모두 CAS 연산을 사용한다는 점을 새롭게 알게 되었다.

AtomicInteger 클래스

멀티 스레드에서 안전한 연산을 지원하기 위한 자바의 클래스로 JDK 1.5부터 지원되었다. 내부적으로 volatile 타입의 int 변수를 가지고 있으며, 해당 변수로 연산을 진행한다. 숫자 기반 클래스를 다루는 도구와 유틸리티에서 동일하게 사용 가능하도록 Number 인터페이스를 확장했다.

public class AtomicInteger extends Number implements java.io.Serializable {

    private static final Unsafe U = Unsafe.getUnsafe();
    private static final long VALUE
        = U.objectFieldOffset(AtomicInteger.class, "value");

    private volatile int value;

    /**
     * Creates a new AtomicInteger with the given initial value.
     *
     * @param initialValue the initial value
     */
    public AtomicInteger(int initialValue) {
        value = initialValue;
    }

    /**
     * Creates a new AtomicInteger with initial value {@code 0}.
     */
    public AtomicInteger() {
    }

    public final int get() {
        return value;
    }

    public final void set(int newValue) {
        value = newValue;
    }

    public final boolean compareAndSet(int expectedValue, int newValue) {
        return U.compareAndSetInt(this, VALUE, expectedValue, newValue);
    }

    public final int incrementAndGet() {
        return U.getAndAddInt(this, VALUE, 1) + 1;
    }

    // 중략
}

주요 메소드

get()

public final int get()

• 현재 값 조회
  

set()

public final void set(int newValue)

• 전달 받은 newValue로 값을 세팅
  

compareAndSet()

public final boolean compareAndSet(int expectedValue, int newValue)

• 현재 값이 expectedValue와 일치하면 newValue로 변경
  

incrementAndGet()

public final int incrementAndGet()

• 현재 값 증가

decrementAndGet()

public final int decrementAndGet()

• 현재 값 감소

유관 클래스

Intger의 원자적 연산을 지원하는 AtmoicInteger 외에도 각 자료형별로 아래와 같이 클래스가 존재한다.

참고 자료

• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/atomic/AtomicInteger.html
• https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.7

[Java] 생산자-소비자 문제와 Object 클래스

개요

이전에는 Object 클래스를 통해 생산자-소비자 문제를 해결하려 하였으나 아래 문제점이 존재했었다.

• 비효율 : 특정 Thread를 깨울 수 없어 동일 타입의 Thread를 깨울 때 비효율 발생 가능
• 기아 상태 : 특정 Thread를 깨울 수 없어 특정 스레드를 제외하고 깨울 수 있는 상황 발생 가능

이번에는 또 다른 해결 방법인 Condition과 BlockingQueue를 알아본다.

Condition 인터페이스

Object의 모니터 락 관련 메서드를 별도의 객체로 분리하여 Lock 구현체와 함께 사용 가능하도록 함으로써 객체당 여러 개의 대기 집합을 갖도록 한다. Lock 인터페이스의 newCondition() 통하여 생성 가능하며, 생성 시 해당 Lock의 스레드 대기 공간을 생성할 수 있다. Condition을 생산자와 소비자 각각 생성함으로써 특정 타입의 Thread를 깨울 수 있도록 처리할 수 있다.

public interface Condition {

    void await() throws InterruptedException;
    void awaitUninterruptibly();
    long awaitNanos(long nanosTimeout) throws InterruptedException;
    boolean await(long time, TimeUnit unit) throws InterruptedException;
    boolean awaitUntil(Date deadline) throws InterruptedException;
    void signal();
    void signalAll();
}

주요 메서드

await()

void await() throws InterruptedException

• 현재 스레드를 WAITING 상태로 condition에 보관
• 호출 시 인터럽트 플래그가 설정되어 있거나 대기 중 인터럽트 발생 시 InterruptedException 발생하고 인터럽트 플래그가 지워짐
• Object.wait()과 유사
  

signal()

void signal()

• condition에서 대기중인 스레드 중 하나를 깨움
• Object.notify()와 유사
  

예제

 class BoundedBuffer<E> {
   final Lock lock = new ReentrantLock();
   final Condition notFull  = lock.newCondition(); // 생산자 Thread 대기
   final Condition notEmpty = lock.newCondition(); // 소비자 Thread 대기

   final Object[] items = new Object[100];
   int putptr, takeptr, count;

   public void put(E x) throws InterruptedException {
     lock.lock();
     try {
       while (count == items.length)
         notFull.await(); // 생산자 Thread 대기
       items[putptr] = x;
       if (++putptr == items.length) putptr = 0;
       ++count;
       notEmpty.signal(); // 소비자 Thread 깨움
     } finally {
       lock.unlock();
     }
   }

   public E take() throws InterruptedException {
     lock.lock();
     try {
       while (count == 0)
         notEmpty.await(); // 소비자 Thread 대기
       E x = (E) items[takeptr];
       if (++takeptr == items.length) takeptr = 0;
       --count;
       notFull.signal(); // 생산자 Thread 깨움
       return x;
     } finally {
       lock.unlock();
     }
   }
 }

BlockingQueue 인터페이스

일반적인 Queue 대비 아래 기능을 추가로 지원하는 큐이다.

• 요소 검색 시 큐가 비어 있지 않을 때까지 기다리는 작업
• 요소 저장 시 큐에 공간이 확보될 때까지 기다리는 작업

public interface BlockingQueue<E> extends Queue<E> {

    boolean add(E e);
    boolean offer(E e);
    void put(E e) throws InterruptedException;
    boolean offer(E e, long timeout, TimeUnit unit) throws InterruptedException;
    E take() throws InterruptedException;
    E poll(long timeout, TimeUnit unit) throws InterruptedException;
    int remainingCapacity();
    boolean remove(Object o);
    boolean contains(Object o);
    int drainTo(Collection<? super E> c);
    int drainTo(Collection<? super E> c, int maxElements);
}

기능별 주요 메서드

대기 시 동작과 기능에 따라 아래와 같이 분류된다.

대기 시 동작

즉시 락을 획득할 수 없는 경우 처리 방법에 따라 아래와 같이 네 가지로 나뉜다.

• Throws exception : 대기 시 예외 발생
• Special value : 연산에 따라 null 또는 false 리턴
• Blocks : 연산 성공 시점까지 무기한 대기
• Times Out : 주어진 최대 시간 제한 동안 대기 후 null 또는 false 리턴
  

주요 구현체

BlockingQueue 인터페이스가 Queue 인터페이스를 상속 받으므로 구현체 모두 Collection Framework에 해당된다.

ArrayBlockingQueue

public class ArrayBlockingQueue<E> extends AbstractQueue<E>
        implements BlockingQueue<E>, java.io.Serializable {

    final Object[] items;
    int takeIndex;
    int putIndex;
    int count;

    final ReentrantLock lock;
    private final Condition notEmpty;
    private final Condition notFull;
}

• 요소를 FIFO(선입선출) 방식으로 정렬
• 새 요소는 대기열의 끝에 삽입
• 고정된 크기의 배열에 요소를 보관하는 전형적인 Bounded Buffer
  

LinkedBlockingQueue

public class LinkedBlockingQueue<E> extends AbstractQueue<E>
        implements BlockingQueue<E>, java.io.Serializable {

     static class Node<E> {
        E item;

        Node<E> next;

        Node(E x) { item = x; }
    }

    private final int capacity;
    transient Node<E> head;
    private transient Node<E> last;

    private final ReentrantLock takeLock = new ReentrantLock();
    private final Condition notEmpty = takeLock.newCondition();

    private final ReentrantLock putLock = new ReentrantLock();
    private final Condition notFull = putLock.newCondition();
}

• 연결된 노드 기반으로 바인딩된 Bounded Buffer
• 요소를 FIFO(선입선출) 방식으로 정렬
• 새 요소는 큐의 끝에 삽입
• 생성 시 사이즈를 지정하지 않으면 사이즈는 Integer.MAX_VALUE
  
  

참고 자료

• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/locks/Condition.html
• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/BlockingQueue.html
• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/ArrayBlockingQueue.html
• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/LinkedBlockingQueue.html
• https://www.baeldung.com/java-blocking-queue
• https://www.baeldung.com/java-queue-linkedblocking-concurrentlinked

개요

• 여러 개의 프로세스를 어떻게 동기화할 것인지에 대한 문제로, 여러 스레드가 동시에 데이터를 생산 및 소비하는 과정에서 발생하는 문제를 말한다.
• 버퍼의 크기가 한정되어 있어 발생하는 문제이기 때문에 한정 버퍼 문제라고도 불린다.
  

문제 상황

한정된 버퍼가 존재하는 상황에서 아래와 같은 상황이 발생할 수 있다.

1. 버퍼가 가득 찬 경우, 생산자는 버퍼에 여유가 생길 때까지 대기
2. 버퍼가 비어있는 경우, 소비자는 버퍼에 데이터가 존재할 때까지 대기
   
   

예상 처리 방안

1. 버퍼가 가득 찬 경우 생산자는 데이터를 생성하지 않거나 버퍼가 빈 경우 소비자는 데이터를 획득하지 않음 (❌)
2. 버퍼가 가득 찬 경우 생산자는 버퍼에 여유가 생길 때까지 대기, 버퍼가 빈 경우 소비자는 버퍼에 데이터가 생성될 때까지 대기 (⭕)

2번 방식으로 처리하기 위해서는 생산자 및 소비자 Thread가 락을 획득하고 무한대기 하지 않도록 아래와 같은 작업이 필요하다.

• 현재 작업이 불가한 경우 락 반납 후 대기
• 작업 후 락을 반납한 뒤 대기중인 Thread를 깨움

이때, Object 클래스의 wait(), notify(), notifyAll() 사용이 가능하다.

Object 클래스의 Thread 동기화 지원

유관 메서드

wait()

public final void wait() throws InterruptedException

• 인터럽트 되거나 깨어날 때까지(Notify 알림을 받을 때까지) 대기
• wait(0L, 0) 이 호출된 것처럼 동작
• 호출 시 Thread의 상태는 WAITING으로 변경
  

notify()

public final void notify()

• wait() 메서드를 통해 해당 객체의 모니터에서 대기중인 Thread 중 하나를 깨움
  • 선택은 임의적이며 구현의 재량에 따라 달라짐
• 현재 락을 획득한 Thread에서 호출 가능, 아닌 Thread가 호출 시 IllegalMonitorStateException 발생
• 해당 메서드 호출을 통해 깨어난 스레드는 락 획득 전까지 진행 불가
  

notifyAll()

public final void notifyAll()

• wait() 메서드를 통해 해당 객체의 모니터에서 대기중인 전체 Thread를 깨움
• 기타 다른 내용은 notify()와 유사
  
  

notify() 의 한계

비효율

• 특정 Thread를 깨울 수 없어 동일 타입의 Thread를 깨울 때 비효율 발생 가능
  • ex) 버퍼가 비어있을 때 소비자 Thread가 다른 소비자 Thread를 깨우는 경우
    

기아 상태

• 특정 Thread를 깨울 수 없어 특정 스레드를 제외하고 깨울 수 있는 상황 발생 가능
  • ex) 생산자 및 소비자 Thread가 WAITING 상태일 때 소비자 Thread들만 깨어날 수 있음
    
    

Javascript의 동시성

위 내용을 작성하던 중 자바스크립트의 동작에 관해 궁금해졌다.

Javascript는 Single Thread로 동작하는 언어라 한 번에 하나의 작업만을 수행할 수 있다.

동시성을 보장하는 비동기, 논블로킹 작업들은 Javascript 엔진을 구동하는 런타임 환경에서 이루어진다.

이때, 런타임 환경이란 브라우저 혹은 Node.js 등을 의미한다.

하지만 정확히는 비동기 프로그래밍 패턴과 이벤트 루프를 통해 동시성을 지원하는 것처럼 보이게 할 수 있게 하는 것인데, 주요 방식은 아래와 같다.

이벤트 루프

• 이벤트 루프를 통해 호출되는 콜백 함수 관리
• 비동기 작업 발생 시 큐에 작업들이 추가되고, 이벤트 루프는 순차적으로 콜백 함수 실행
  

비동기 처리

async function fetchData() {
    try {
        let response = await fetch('https://api.example.com/data');
        let data = await response.json();
        console.log(data);
    } catch (error) {
        console.error(error);
    }
}
fetchData();

• Promise : 비동기 작업의 완료 또는 실패를 나타내는 객체
• async : function 앞에 사용하여 비동기 함수 정의
• await : [rv] = await expression; 형태로 사용되며, 프로미스를 기다리기 위해 사용
  • async function 내부에서만 사용 가능

참고 자료

• https://ko.wikipedia.org/wiki/생산자-소비자_문제
• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Object.html
• https://meetup.nhncloud.com/posts/89
• https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Operators/await
• https://inpa.tistory.com/entry/🔄-자바스크립트-이벤트-루프-구조-동작-원리#자바스크립트_이벤트_루프_동작_과정

synchronized 사용 시 발생하는 아래 문제점을 극복하기 위해 자바 1.5부터 Lock 인터페이스와 기본 구현체인 ReentrantLock을 제공하게 되었다.

synchronized 한계

1) 무한 대기

• 락 획득 시까지 BLOCKED 상태 유지
• 이때 특정 시간동안 이후 발생하는 타임 아웃이나 인터럽트를 통한 대기 중단이 불가

2) 공정성

• BLOCKED 상태의 스레드 중 어느 스레드가 락을 획득할지 알 수 없음

3) 유연성 저하

• 모든 락의 획득과 해제가 블록 구조 방식으로 이루어지므로 여러 개의 락 획득 시 획득 순서와 반대로 해제 필요
• 또한, 락의 해제는 락 획득 시 범위와 동일한 범위에서 해제 필요
  
  

🔒 Lock 인터페이스

Lock 인터페이스 구현 시 Lock의 획득과 해제에 대하여 synchronized 방식에 비해 유연성이 증가하게 된다.

락의 해제 시 획득 순서와 동일하지 않아도 되는 등 보다 유연성을 가지지만 구현 시 책임을 가지게 된다.

package java.util.concurrent.locks;

import java.util.concurrent.TimeUnit;

/**
 * (중략)
 * @see ReentrantLock
 * @see Condition
 * @see ReadWriteLock
 * @jls 17.4 Memory Model
 *
 * @since 1.5
 */
public interface Lock {

    void lock();
    void lockInterruptibly() throws InterruptedException;
    boolean tryLock();
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
    void unlock();
    Condition newCondition();
}

메소드

lock()

void lock();

• 락 획득
• 다른 스레드가 락을 획득한 경우 스레드는 대기
• 인터럽트에 응답하지 않음
  

lockInterruptibly()

void lockInterruptibly() throws InterruptedException;

• lock()과 달리 락 획득 대기 중 인터럽트 발생 시 InterruptedException 발생 후 락 획득 포기
  

tryLock()

boolean tryLock();

• 락 획득 시도 후 획득 여부 반환
• 획득 성공 여부를 즉시 반환하므로 인터럽트에 응답할 필요 없음
  

tryLock(long time, TimeUnit unit)

boolean tryLock(long time, TimeUnit unit) throws InterruptedException;

• 매개변수의 시간 동안 락 획득 시도
• 대기 중 인터럽트 발생 시 InterruptedException 발생 후 락 획득 포기
  

unlock()

void unlock();

• 락 해제
• 락을 획득한 스레드가 호출해야 함
  

newCondition()

Condition newCondition();

• 락과 결합하여 사용 가능한 Condition 객체 생성 후 반환
• Condition 객체는 스레드가 특정 조건을 기다리거나 신호를 받을 수 있도록 함
  

사용 방법

보통 아래와 같은 관용구를 사용하게 된다.

 Lock l = ...;
 l.lock();
 try {
   // 임계 구역: 락에 의해 자원 접근 시 보호됨
 } finally {
   l.unlock();
 }

• 락 획득/해제가 서로 다른 범위에서 발생하는 경우 락이 유지되는 동안 실행되는 모든 코드가 try~catch , try~finally로 보호되어 필요 시 잠금이 해제될 수 있도록 해야 한다.
  

유의 사항

세 가지 형태의 락 획득 방식(인터럽트 가능/불가능, 타이밍 적용)은 성능/순서 보장 등에서 차이가 존재할 수 있다.

구현체는 세 가지 형태의 락 획득 방식에 대해 동일하게 보장할 필요가 없으며, 진행 중인 락 획득의 인터럽트를 지원할 의무도 없다.

락 획득 시 인터럽트를 지원하는 경우, 인터럽트는 락 획득 전체 과정에서 지원되거나, 메서드 진입 시에만 지원될 수 있다.

🔐 Lock 구현체

인터페이스를 직접 구현하여 사용할 수도 있지만 자바에서는 다양한 구현체를 제공한다.

대표적인 구현체는 아래와 같으며, 구현체마다 세부 구현사항이 다를 수 있어 사용 시 확인 후 사용하는 것이 좋다.

1) ReentrantLock

synchronized 메서드 및 구문을 통해 접근하는 모니터 락과 동일한 동작을 하며 추가 기능을 제공하는 재진입 가능한 상호 배제 락이다.

여기서 말하는 재진입은 동일한 스레드가 동일한 락을 여러 번 걸 수 있다는 의미이다.

마지막으로 락을 획득했지만 아직 해제하지 않은 스레드가 락을 소유하게 된다.

동일한 스레드 내 최대 2,147,483,647번의 재귀적 락을 지원하며, 한도 초과 시 락 메서드에서 Error 예외를 발생시킨다.

공정성과 공정/비공정 모드

public class ReentrantLock implements Lock, java.io.Serializable {
    private final Sync sync;

    ... 중략...

      public ReentrantLock() {
        sync = new NonfairSync(); // 비공정 모드
    }

    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync(); // 매개변수가 true일 경우 공정 모드
    }

    ... 중략...
}

• 생성자에 공정성 여부를 true로 넘길 경우, 경쟁 상황에서 가장 오랫동안 대기한 스레드에 락을 부여하는 것을 우선시하여 기아 현상이 발생하지 않도록 보장한다.
• 비공정 모드인 경우 특정 접근 순서를 보장하지 않는 대신 성능은 공정 모드에 비해 좋다.
• 하지만 락의 공정성이 스레드 스케줄링의 공정성을 보장하지는 않는다.
• tryLock() 메서드는 공정성을 따르지 않으며, 다른 스레드가 대기중이어도 락을 사용할 수 있으면 true 로 반환됨

메서드

isHeldByCurrentThread()

public boolean isHeldByCurrentThread() {
    return sync.isHeldExclusively();
}

• 현재 스레드가 해당 락을 소유하고 있는지 확인
• 소유하고 있을 경우 true, 아닐 경우 false 반환

getHoldCount()

public int getHoldCount() {
    return sync.getHoldCount();
}

• 현재 스레드가 해당 락을 몇 번 획득하고 있는지 반환, 이는 재진입 횟수를 의미

사용 예시

 class X {
   private final ReentrantLock lock = new ReentrantLock();
   // ...

   public void m() {
     lock.lock();
     try {
       // 임계 영역
     } finally {
       lock.unlock();
     }
   }
 }

2) ReentrantReadWriteLock

ReentrantLock 과 유사하지만 읽기/쓰기 전용 락을 각각 가지고 있다는 점에서 차이가 있다.

또한, 특정 종류의 컬렉션을 사용할 때 동시성 개선에 사용될 수 있다.

단, 컬렉션이 크고, 쓰기보다 읽기 작업이 많고 동기화 오버헤드보다 더 큰 오버헤드를 가지는 작업인 경우에만 유용하다.

공정성과 공정/비공정 모드

 public class ReentrantReadWriteLock implements ReadWriteLock, java.io.Serializable {
    private final ReentrantReadWriteLock.ReadLock readerLock
    private final ReentrantReadWriteLock.WriteLock writerLock;
    final Sync sync;

    public ReentrantReadWriteLock() {
        this(false); // 비공정 모드
    }

    public ReentrantReadWriteLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync(); // true일 경우 공정 모드
        readerLock = new ReadLock(this);
        writerLock = new WriteLock(this);
    }

    public ReentrantReadWriteLock.WriteLock writeLock() { return writerLock; }
    public ReentrantReadWriteLock.ReadLock  readLock()  { return readerLock; }

    ... 중략 ...
}

• ReentrantLock 과 동일하게 공정/비공정 모드 선택이 가능하다.

락의 강등

 class CachedData {
   Object data;
   boolean cacheValid;
   final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

   void processCachedData() {
     rwl.readLock().lock();
     if (!cacheValid) {
       rwl.readLock().unlock();
       rwl.writeLock().lock();
       try {
         if (!cacheValid) {
           data = ...;
           cacheValid = true;
         }
         rwl.readLock().lock();
       } finally {
         rwl.writeLock().unlock(); // 읽기 락 획득 후 쓰기락 해제를 통한 락 강등
       }
     }

     try {
       use(data);
     } finally {
       rwl.readLock().unlock();
     }
   }
 }

• 쓰기 스레드는 읽기 락을 획득할 수 있지만, 반대의 경우는 불가능하다. (ex. 쓰기 락을 보유한 스레드가 읽기 락 획득 가능)
• 이러한 특성으로 인해 쓰기 락을 획득한 상태에서 읽기 락을 획득한 경우 쓰기 락을 해제하여 락의 등급을 강등시킬 수 있으나, 읽기 락을 쓰기 락으로 업그레이드는 불가능하다.
  

3) StampedLock

읽기/쓰기 접근 제어를 위해 세 가지 모드를 제공하는 권한 기반의 락이며, 자바 1.8부터 제공되었다.

StampedLock의 상태는 버전과 모드로 구성되고, 락 획득 메서드는 락 상태에 따른 접근을 제어할 수 있고 락의 상태를 나타내는 식별자인 스탬프를 반환한다.

락 해제 및 변환 메서드는 스탬프를 매개변수로 받아 락 상태와 일치하지 않으면 실패한다.

다른 구현체와 달리 Lock 또는 ReadWriteLock 인터페이스를 직접 구현하지 않았다.

public class StampedLock implements java.io.Serializable {
    ... 중략 ...

    private transient volatile Node head;
    private transient volatile Node tail;

    transient ReadLockView readLockView;
    transient WriteLockView writeLockView;
    transient ReadWriteLockView readWriteLockView;

    private transient volatile long state;
    private transient int readerOverflow;

    public StampedLock() {
        state = ORIGIN;
    }

    ... 중략 ...
}

모드

스탬프를 어떤 방식으로 획득하였는지에 따라 아래와 같이 나뉜다.

1. 쓰기 모드 : writeLock() 사용 시
2. 읽기 모드 : readLock() 사용 시
3. 낙관적 읽기 모드 : tryOptimisticRead() 사용 시

모드 업그레이드

tryConvertToWriteLock(long stamp) 메서드를 통해 아래 상황에서 쓰기 모드로의 업그레이드를 지원한다.

• 이미 쓰기 모드인 경우
• 읽기 모드이고 다른 읽기 스레드가 없는 경우
• 낙관적 읽기 모드이고 락이 사용한 경우

주의사항

• 재진입이 불가하여 락이 걸린 상태에서 락을 획득하려고 하면 안 된다.
• 스케줄링 시 읽기 모드나 쓰기 모드와 같은 특정 모드를 우선시 하지 않음
• try~ 메서드는 공정성을 보장하지 않을 수 있음
  
  

📚 참고 자료

• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/locks/Lock.html
• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html
• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/locks/ReentrantReadWriteLock.html
• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/locks/StampedLock.html
• https://www.baeldung.com/java-concurrent-locks

멀티 스레드를 사용하는 상황에서 Runnable을 구현하여 실행한 다수의 Thread가 Thread 내부 변수의 변경된 값을 읽지 못하는데, 이러한 문제를 메모리 가시성 문제라고 한다.

예시

public class TaskRunner {

    private static class Task implements Runnable {

        boolean flag = true;

        @Override
        public void run() {
            while (!flag) {}

            System.out.println("Task 종료");
        }
    }

    public static void main(String[] args) {
        Task task = new Task();
        task.start();

        task.flag = false;
    }
}

🔎 원인

문제는 상대적으로 속도가 느린 메모리의 접근 횟수를 줄이기 위해 값을 캐싱하여 사용하는 데 있다. 캐시는 메모리 중 일부를 미리 가져오고 CPU는 메모리에 접근 전 먼저 캐시 내 원하는 데이터가 존재하는지 확인한다. 이때 L1 ➡ L2 ➡ L3 순으로 캐시 검색 후 캐시 미스 시 메모리를 조회한다.

위 코드 기준으로 Task Thread는 메모리에 반영된 변경 값(false)이 캐시에 반영 전까지 flag 변수를 true로 참조하여 예상대로 동작하지 않는 것이다.

캐시 구조

L1 ➡ L2 ➡ L3 순으로 속도가 점차 느려지며, 용량은 커진다. 일부 캐시는 프로세서별로 구조가 상이할 수 있다.

L1 캐시

• 직접 레지스터에 연결된 캐시로, 명령어 캐시와 데이터 캐시가 존재
• 명령어와 데이터를 구분하여 조회하는 특수 캐시
• 캐시 중 가장 빠르고 용량이 작음

L2 캐시

• CPU 코어 또는 코어 근처에 위치하여 코어별로 사용되거나 코어들이 공유
• L1 캐시가 커버하지 못하는 데이터와 명령어 저장

L3 캐시

• CPU 내부에 위치
• 캐시 중 가장 용량이 큼

🚌 버스란?

• 메인보드에서 각 장치를 연결하여 데이터가 지나다니는 통로

🚌 CPU 내부 버스란?

• CPU 내부 장치를 연결하는 버스로, BSB(Back Side Bus) 또는 후면 버스라 불림

🚌 시스템 버스란?

• 메모리와 주변 방치를 연결하는 버스로, FSB(Front Side Bus) 또는 전면 버스라 불림
• 메인보드의 동작 속도를 의미

캐시 히트와 캐시 미스

캐시 히트

• 캐시에서 원하는 데이터를 찾은 경우

캐시 미스

• 캐시에서 원하는 데이터를 찾지 못하여 메모리 내 데이터를 조회하는 경우

일반적인 컴퓨터의 캐시 적중률은 약 90%라고 한다.

🔑 해결 방법

Thread 내 공유 변수에 volatile 키워드를 사용한다. 단, 메모리 내 데이터를 직접 읽고 쓰기 때문에 성능은 저하된다.

사용하지 않을 경우 캐시 메모리 갱신 전까지 메모리와 캐시 간 데이터가 일치하지 않는 문제가 발생할 수 있다. 주로 컨텍스트 스위칭 시 캐시 메모리도 함께 갱신되지만 이는 달라질 수 있다.

public class TaskRunner {

    private static class Task implements Runnable {

        volatile boolean flag = true; // volatile 키워드 사용!

        @Override
        public void run() {
            while (!flag) {}

            System.out.println("Task 종료");
        }
    }

    public static void main(String[] args) {
        Task task = new Task();
        task.start();

        task.flag = false;
    }
}

🔧 함께 알아두기

저장 장치 계층 구조

레지스터 ➡ 캐시 ➡ 메모리 ➡ 저장장치

위 순으로 속도가 느려지며, 용량은 커진다.

캐시 내 변경사항 반영 방법

캐시 내 변경사항을 메모리에 반영하는 방법은 아래와 같다.

1) 즉시 쓰기 (Write Through)

• 캐시 내 데이터 변경 즉시 메모리에 반영
• 메모리와의 빈번한 데이터 전송으로 성능 저하

2) 지연 쓰기 (Write Back)

• 캐시 내 데이터 변경 시 변경사항을 모아 주기적으로 반영
• 성능상 이점이 존재하지만 메모리와 캐시 간 데이터 불일치 발생 가능

📚 참고 자료

• [도서] 쉽게 배우는 운영체제
• https://it.donga.com/215/
• https://www.baeldung.com/java-volatile

Thread.sleep() 은 Thread가 특정 시간동안 대기해야 할 때 사용되는 메서드

테스트 시 사용되는 등 종종 아래와 같이 사용될 때가 있음

예시

public static void sleep(long millis) {
    try {
        Thread.sleep(millis);
    } catch (**InterruptedException ex**) {
        // 적절히 처리 필요!
    }
}

InterruptedExcpetion

위와 같이 Thread.sleep() 에서 지정한 시간이 지나면 발생하는 체크 예외로, 아래 조건에서 발생

발생 원인

• Thread가 대기중 또는 Thread.sleep()와 같이 수면중이거나 다른 방식으로 점유중일 때 발생하고, 활동 전 또는 활동 중에 스레드가 중단될 때 발생

활용 방안

현재 스레드의 인터럽트 여부 확인 후 아래와 같이 예외 발생시킬 수 있음

if (thread.interrupted()) throw new InterruptedException();

인터럽트란?

Thread에 하던 일을 중단하라는 신호를 보내기 위해 사용

동작 방식

1. 특정 Thread에 인터럽트를 발생시키기 위해 해당 Thread의 interrupt() 메서드 호출
2. 해당 Thread의 인터럽트 플래그가 true 로 변경
3. 특정 조건에 해당되지 않는 경우 현재 Thread에 인터럽트 상태 설정 (interrupt() 참고)
   

인터럽트 발생 여부 확인 방안

1. InterruptedException 예외가 발생 여부 확인 (❌)
   • 인터럽트 발생 시 항상 예외가 발생하는 것이 아니므로 올바른 방법이 아님
2. interrupted(), isInterrupted() 호출을 통해 Thread 내 인터럽트 플래그 확인 (⭕)
   

유관 메서드

interrupt()

public void interrupt()

• 현재 Thread가 수정될 수 없는 상태인 경우 SecurityException 발생 가능
• 아래 조건에 해당되지 않는 경우 현재 Thread에 인터럽트 상태 설정
  • wait(), join(), sleep() 메서드에서 호출이 차단되면 인터럽트 플래그가 false로 변경되고 InterruptedException 발생
  • Thread가 InterruptibleChannel 의 I/O 작업에서 블로킹된 상태인 경우 인터럽트 플래그가 true로 설정되고 ClosedByInterruptException 발생
  • Selector에서 차단된 경우 Thread 인터럽트 플래그를 true로 설정 후 선택 작업을 0이 아닌 값으로 즉시 반환
• 살아 있지 않은 Thread를 인터럽트하면 소용 없음

💡 InterruptibleChannel이란?

• java.nio.channels 패키지 내 클래스로, 비동기적으로 닫고 중단 가능한 네트워크 연결에 사용되는 채널
• FileChannel, SocketChannel 등이 해당 인터페이스를 구현

💡 Selector란?

• Non-Blocking I/O 연산을 관리하는 데 사용
• 단일 스레드로 여러 네트워크 채널의 I/O 이벤트를 효율적으로 처리 가능

interrupted()

public static boolean interrupted()

• 현재 Thread의 중단 여부 판단
• 호출 시 Thread가 인터럽트 상태라면 true 반환 후 인터럽트 플래그는 false로 변경됨
• 살아 있지 않은 Thread인 경우 false 반환
  

isInterrupted()

public boolean isInterrupted()

• 현재 Thread의 중단 여부 판단
• interrupted()와 달리 인터럽트 플래그 변경을 진행하지 않음
• 살아 있지 않은 Thread인 경우 false 반환

📚 참고 자료

• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Thread.html#interrupted()
• https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/InterruptedException.html
• https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html
• http://happinessoncode.com/2017/10/09/java-thread-interrupt/

일부 프로젝트에서 Git-Flow 를 통해 Feature 브랜치를 생성할 때 develop 브랜치가 아닌 기존에 존재하던 다른 이름의 브랜치를 Base로 생성하는 방법이 필요하게 되었다.

해당 프로젝트는 개발 초기부터 Git-Flow 를 통해 개발을 진행하지 않아 develop 이 아닌 다른 브랜치를 develop 브랜치처럼 사용하고 있었기 때문이다.

🔑 해결 방법

1. 해당 프로젝트가 존재하는 폴더 하위의 .git 폴더로 이동한다.

2. config 파일을 열어서 아래 내용을 수정한다.

[gitflow "branch"]
    master = {git-flow의 master 역할을 할 브랜치}
    develop = {git-flow의 develop 역할을 할 브랜치}

📕 느낀 점

• 까먹기 전에 자주 자주 기록해두어야겠다. 😂

3 주차

수, 목 | Assignment #16

• 📚 복습
• ✔️ 미션 Mission(4)

Mission(4)

📌 인상깊은 10가지 TIP

1. 어설픈 변명 말고 대안을 제시하라. → 변명하는 대신 대안을 제시하라. 그 일은 할 수 없다고만 말하지 말고, 무엇을 할 수 있는지 설명하라.

2. 최종 결정이란 없다. → 돌에 새겨진 것처럼 바뀌지 않는 결정은 없다. 모든 결정이 바닷가의 모래 위에 쓰인 글씨라 생각하고 변화에 대비하라.

3. 여러분은 완벽한 소프트웨어를 만들 수 없다. → 소프트웨어는 완벽할 수 없다. 불가피한 오류로부터 여러분의 코드와 사용자를 보호하라.

4. 우연에 맡기는 프로그래밍은 하지 말라. → 믿을 만한 것만 믿어야 한다. 우발적인 복잡성에 주의하고, 우연한 행운을 목적을 가지고 세운 계획으로 착각하지 말라.

5. 일찍 리팩토링하고, 자주 리팩토링하라. → 정원의 잡초를 뽑고 식물 배치를 바꾸는 것과 같이 코드도 필요할 때마다 다시 작성하고, 다시 작업하고, 아키텍처를 다시 만들라. 근본적인 문제를 해결하라.

6. 테스트할 수 있도록 설계하라. → 코드를 쓰기 전 테스트에 대해 먼저 생각하라.

7. 요구 사항은 피드백을 반복하며 알게 된다. → 요구 사항을 이해하려면 탐험과 피드백을 거쳐야 한다. 결정한 요구 사항의 여파를 바탕으로 처음의 발상을 다듬는다.

8. 생각의 틀을 벗어나지 말고, 틀을 찾아라. → 불가능한 문제와 마주쳤다면 진짜 제약 조건을 찾아라. 스스로 물어보라. '정말로 반드시 이렇게 해야 하나? 꼭 해야 하는 일이긴 한가?'

9. 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다. → 당연하다.

10. 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라. → 사용자의 사업 가치를 창조하는 해법을 개발하라. 실행할 것이다.

📒 챌린지 후기

• 클린코드 챌린지 완주 직후에 야근 등 다른 일과 병행하며 '새로운 챌린지를 또 해낼 수 있을까?', '완주 못할 바에는 시작도 하지 않는 게 낫지 않을까?'란 생각이 챌린지 시작 전에 자꾸만 떠올랐었다. 하지만 막상 시작해보니 3주는 금방 흘러갔고 벌써 두 번째의 챌린지를 완주하게 되어 뿌듯하다. 그리고 정해진 챌린지 일정을 진행해야 하다 보니 약간의 강제성이 부여되어 하차하지 않고 평소에 읽고 싶었던 책을 다 읽을 수 있게 된 것 같다.
• 최근에는 특정 기술만을 다루는 기술 서적을 주로 읽었던 것 같은데 이러한 책을 읽다보니 "개발자"라는 직업에 대한 생각이 많아졌는데 앞으로도 종종 이러한 류의 책을 읽어야겠다고 생각했다.

3 주차

화 | Assignment #15

• 📚 9장. 실용주의 프로젝트
• ✔️ TIL

9장. 실용주의 프로젝트

📘 책에서 기억하고 싶은 내용

• 개요

  • 실용주의 기법들을 개인이 아닌 팀에 확장하여 적용시키면 이점이 몇 배로 많아진다.

• 실용주의 팀 (p.378)

  • 실용주의 팀은 작다.
    • 구성원이 대략 10~12명 이하
    • 구성원이 추가되거나 빠지는 일은 거의 없음
    • 모두가 서로 잘 알고, 신뢰하며, 의존해야 함
  • 팀 전체가 깨진 창문을 용납하지 않아야 한다.
  • 품질은 팀원 모두가 제각기 기여할 때만 보장된다. (품질은 애초에 제품에 포함된 것)
  • 모든 사람이 적극적으로 환경 변화를 감시하도록 권장해야 한다.
  • 우리 팀이 진정 개선하고 혁신하고 싶다면 계획을 세워야 한다. → "시간이 나면 그때" 하겠다는 것은 "영원히 하지 않겠다"는 것
  • 팀의 지식 포트폴리오 계획
    • 구형 시스템 유지 보수 : 미루지 말고 처리하라
    • 프로세스 회고와 개선 : 무엇이 잘되고 잘되지 않았는지 지속적인 확인을 통한 계획 수립 및 변경 필요
    • 새로운 기술 탐험 : 유행한다는 이유로 도입하지 말고 프로토타이핑을 통하여 신중한 조사 필요
    • 학습 및 기술 갈고 닦기 : 많은 기술을 팀원들에게 전도할 계획을 세워라(스몰토크, 스터디 등)
  • DRY 원칙 을 지키기 위해서는 팀원 서로에게 관심을 유지하라. (동료의 업무 등)
  • 예광탄을 내가 맡은 업무가 아닌 전체 업무 영역에서 활용해보자. (UX, F/E, B/E, Server, DB, QA 등)
  • 팀은 개인들로 이루어진다. 각 팀원

• 코코넛만으로는 부족하다 (p.387)

  • 유행하는 것(정책, 프로세스 등)이 아니라 성공 사례와 동일한 제약 조건을 가지고 있는지 확인하여 실제로 잘 맞는 것을 새용해야 한다.
  • "잘 맞는 것" 을 어떻게 알까? → 실용주의 기법을 적용하여 실험하며 좋은 부분만 유지
  • 소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것이므로, 어떤 특정 방법론에서 가장 좋은 부분만 가져다가 적절히 조정하여 사용해야 한다.
  • 특정 방법론에 과도하게 투자하면 다른 대안을 보지 못하게 될 수도 있다.

• 실용주의 시작 도구 (p.392)

  • "테스팅은 버그의 존재만 보여줄 수 있지 버그의 부재까지는 보여줄 수 없다." - 데이크스트
  • 버전 관리 , 가차 없는 테스트 , 전체 자동화 는 프로젝트에 필수적인 견고한 기반이다.
  • 빌드/릴리즈/테스트/문서 등 프로젝트에서 거듭 발생하는 작업은 모두 자동화가 필요하다.
  • 많은 개발자들이 무의식적으로 코드가 어디에서 깨지는지 파악하고서는 약한 지점을 피해 다니면서 살살 테스트하려 한다.
  • 일찍 테스트하고, 자주 테스트하라. 테스트를 자동화하라.
  • 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.
  • 빌드 과정에는 테스트 주요 유형이 포함되어야 한다. (단위 테스트, 통합 테스트, 성능 테스트 등)
  • 어떤 버그를 감지해 내는 테스트를 작성한 후에, 그 버그가 의도적으로 생기도록 한 다음 테스트가 경보를 울리는지 확인하라.
  • 코드 커버리지 보다 중요한 것은 프로그램이 갖는 상태 이다.

• 사용자를 기쁘게 하라 (p.402)

  • 모든 팀 구성원이 사용자가 기대하는 바를 완전히 이해해야 한다.
  • 결정을 내릴 때면 어떤 선택이 사용자의 기대에 더 가깝게 가는 길인지 생각해보아야 한다.
  • 이런 기대를 염두에 두고 사용자의 요구 사항을 비판적으로 분석하라.
  • 프로젝트를 진행하면서도 계속 사용자의 기대에 대하여 생각하라.
  • 실용주의 프로그래머의 본질은 "문제 해결사"고, 문제를 해결한다.

• 오만과 편견 (p.404)

  • 자신의 작품에 서명하는 것을 자랑스러워할 수 있어야 한다.
  • 자신의 코드만 좋게 보고 동료들의 코드는 깎아내리는 편견을 갖지 마라.
  • 경계심 때문에 나의 코드를 참견하는 사람으로부터 방어하려고 해서는 안 된다.

🤔 소감 및 생각

• 드디어 마지막 챕터를 다 읽었다. 책을 다 읽고 나니 앞으로 내가 어떻게 해야 할지 한참을 고민하게 되었다. 책에서 말하는 실용주의 기법은 완전히 새로운 것이 아닌, 대부분 모두가 알고 있지만 지키기 어려운 원칙이었던 것 같다.
• 읽으면서 '아 이런 부분은 실무에서 이러한 사유때문에 적용하기 어려울텐데' 이런 생각을 자주 하였는데, 이런 방어적인 생각때문에 나와 팀이 더 발전할 기회를 놓쳤을 수도 있다는 생각이 들었다. 사소한 부분이라도 반복되는 업무는 자동화를 하며 업무 시간을 코드 작성에 많이 할애할 수 있도록 노력해야겠다.

🔍 새롭게 또는 다시 알게 된 내용

• NONE

3 주차

월 | Assignment #14

• 📚 복습
• ✔️ 미션 Mission(3)

Mission(3)

📌 연습문제 33

다음 문장들이 진정한 요구 사항인가? 가능하다면 진정한 요구사항이 아닌 것을 좀 더 유용하게 고쳐 써 보라.

1. 응답시간은 500ms 이하여야 한다.

• 📖 책의 해답

  • 이 문장은 진짜 요구 사항처럼 보인다. 환경 때문에 애플리케이션에 제약을 추가해야 할 수 있다.

• 💡 나의 해답

  • 아래 내용에 대하여 추가적으로 확인이 필요하다.
    • 이 속도가 최소 요구 조건인지?
    • 응답시간 측정 시 시작 시간의 기준이 API 호출 직후인지, 클라이언트에서 사용자가 액션을 한 시점인지
    • 타 시스템 API 사용 등 여러 요인으로 인하여 응답시간이 최소 500ms 이상인 경우에는 기능을 제외할 것인지
    • 네트워크 속도(성능) 수준은 어떤지

2. 모달 창의 바탕색은 회색이다.

• 📖 책의 해답

  • 이 문장 자체만으로는 진짜 요구사항이 아니다. 하지만 진짜로 무엇이 필요한지 알아내려면 마법의 질문을 던져야 한다. ”왜?”(중략)

• 💡 나의 해답

  • UI 요구사항의 아래 항목에 대하여 추가적으로 확인이 필요하다.
    • 글자색
    • 버튼 등 컴포넌트의 표준 색상
    • 표준 레이아웃

3. 애플리케이션은 프론트엔드 프로세스 몇 개와 백엔드 서버로 구성된다.

• 📖 책의 해답

  • 이 문장은 요구사항이 아니다. 이것은 아키텍처다. 이런 종류의 것과 마주쳤다면 사용자가 무슨 생각을 하는지 알아내기 위해 깊이 파고들어야 한다.

• 💡 나의 해답

  • 전체적인 요구사항 파악 후 인프라 및 아키텍처 설계가 가능함을 설명하기 전, 해당 항목의 진짜 의도를 파악하기 위해 질문한다.

4. 사용자가 숫자가 아닌 글자를 숫자 필드에 입력하면 시스템은 입력 필드를 깜빡이고 입력을 거부한다.

• 📖 책의 해답

  • 밑에 숨겨진 요구 사항은 아마 “시스템은 사용자가 필드에 올바르지 않은 값을 입력하는 것을 막는다. 올바르지 않은 값을 입력하는 경우 경고를 보낸다.”라는 문장에 더 가까울 것이다.

• 💡 나의 해답

  • 입력을 거부할 때 어떤 방식으로 거부가 필요할지 확인이 필요하다.
    • 알림창 또는 팝업 조회
    • 입력 필드 하단에 문구 표시
    • 별도 표시 없이 숫자에 한하여 입력받도록 처리

5. 이 임베디드 애플리케이션의 코드와 데이터 크기는 32Mb 이내여야 한다.

• 📖 책의 해답

  • 이 문장은 하드웨어의 규격에 맞춘 것 같아 보인다. 아마 꼭 지켜야 하는 요구 사항일 것이다.

• 💡 나의 해답

  • 아래 내용에 대하여 추가적으로 확인이 필요하다.
    • 각 소스 파일별 크기가 32MB 이하여야 하는지
    • 용량 제한이 필요한 데이터의 기준이 무엇인지에 대한 정의

3 주차

일 | Assignment #13

• 📚 8장. 프로젝트 전에
• ✔️ TIL

8장. 프로젝트 전에

📘 책에서 기억하고 싶은 내용

• 요구 사항의 구렁텅이 (p.350)

  • 요구사항은 피드백을 반복하며 알게 된다.
  • 정책은 메타데이터다. 현재의 정책 정보는 시스템이 지원하는 것들 중 한 사례일 분이고, 시스템은 다양한 정책을 처리할 수 있도록 일반적으로 구현해야 한다.
  • 요구 사항 문서는 개발자의 계획을 위해서 쓰는 것이다.
  • 좋은 요구 사항은 추상적이다. 사업에 필요한 사항을 정확히 반영하는 가장 간단한 표현이 좋다.
  • 요구 사항이 슬금슬금 추가되는 것을 어떻게 막을 수 있을까? → 반복 주기를 거치며 의뢰인과 정기적으로 피드백을 주고 받는다. ("딱 한 기능만 더"란 요청이 미치는 영향을 알도록)
  • 프로젝트 용어 사전을 만들고 관리하라.
    • 프로젝트에서 사용하는 모든 용어와 어휘를 모아 놓은 단 하나의 장소여야 하고, 온라인 문서가 적합하다.

• 불가능한 퍼즐 풀기 (p.362)

  • 그럴싸해 보이는 제약 조건이 사실은 전혀 제약 조건이 아닐 수도 있다.
  • 생각의 틀을 벗어나지 말고, 틀을 찾아라. (틀 = 제약 조건)
  • 불가능한 문제처럼 보인다면 잠시 딴짓을 하거나 동료와 이야기를 통해 해결을 시도해보라.

• 함께 일하기 (p.367)

  • 짝 프로그래밍 : 개발자 한 명은 키보드를 조작하지만 다른 한 명은 하지 않으며, 키보드 담당은 필요에 따라 바꿀 수 있고 둘이 함께 문제를 푼다.
  • 몹 프로그래밍 : 셋 이상의 사람이 참여하는 짝 프로그래밍의 확장 방안, 실시간 코딩을 곁들인 밀접한 협업
    • 세 명 이상의 사람은 반드시 개발자가 아니어도 된다. (테스트, 고객 모두 가능)
  • 유의사항 및 TIP
    • 누가 가장 똑똑한지 겨루는 것이 아니다.
    • 코드만 비판하고 사람을 비판하지 말라.
    • 다른 사람의 관점을 듣고 이해하려고 노력하라.
    • 자주 회고를 하라.

• 애자일의 핵심 (p.372)

  • 애자일 프로세스라는 것은 있을 수 없다. 애자일의 가치는 할 일을 결정할 떄 무엇을 추구해야 할지를 알려준다.
  • 애자일의 가치
    • 공정과 도구 < 개인과 상호작용
    • 포괄적인 문서 < 작동하는 소프트웨어
    • 계약 협상 < 고객과의 협력
    • 계획을 따르기 < 변화에 대응하기
  • 애자일하게 일하기
    • 아래 과정을 프로젝트 종료 시까지 반복하라.
      • 내가 어디에 있는지 알아내라.
      • 도달하고 싶은 곳을 향하여 의미 있는 발걸음을 가능한 한 작게 옮겨라.
      • 어디에 도착했는지 평가하고, 망가트린 것이 있으면 고쳐라.
  • 지속적으로 프로세스를 실험하지 않는 팀은 애자일 팀이 아니다.
  • 애자일이 전반적으로 작동하게 하려면 무언가를 바꾸기 쉽도록 좋은 설계를 만들어야 한다. 바꾸기 쉽다면 모든 층위에서 아무런 주저 없이 문제를 바로 잡을 수 있을 것이다.

🤔 소감 및 생각

• 요구 사항이 추가되는 것을 막을 수 있는 방법을 논하는 내용을 읽을 때 많이 공감되면서도 씁쓸했다. 고객은 늘 요구 사항을 한 번에 결정하지 못하고, 지속적으로 "슬그머니" 추가하였는데, 책에서 말하는 답과 같이 피드백을 통해 관리하려고 하였으나 결국엔 "기간을 넉넉하게 드릴테니 그때까지라도 부탁드려요"라는 말이 돌아왔었다. 내가 속했던 프로젝트 팀의 대부분은 결국 기간을 연장하여 모든 요구사항을 수용하는 방향으로 결정하였는데, 이러한 상황에서 요구 사항을 줄일 다른 방법이 있는지 다시 생각해보게 되었다.

🔍 새롭게 또는 다시 알게 된 내용

• NONE

3 주차

금, 토 | Assignment #12

• 📚 7장. 코딩하는 동안
• ✔️ TIL

7장. 코딩하는 동안

📘 책에서 기억하고 싶은 내용

• 개요 (p.273)

  • 프로젝트가 실패하는 가장 큰 원인은 설계 내용을 컴퓨터가 실행할 수 있는 문장으로 바꾸는 일만 하면 된다는 생각이다.
  • 적극적으로 자기 코드에 대해 생각하지 않는 프로그래머는 우연에 맡기는 프로그래밍을 하는 것이다.

• 파충류의 뇌에 귀 기울이기 (p.275)

  • 파충류의 뇌 = 동물적인 본능
  • 코딩이 평소와 다르게 오르막길과도 같다면 지금 하는 작업이 필요 이상으로 어떤 원인으로 인하여 힘들어지고 있는 것일수도 있다.
  • 휴식 및 동료에게 설명하는 방법으로 해결되지 않는다면 프로토타이핑을 시도해봐라.
    • 이때, 꺼림칙했던 느낌이 코딩 도중에 갑자기 명확한 문제로 구체화되면 즉각 해결하라.

• 우연에 맡기는 프로그래밍 (p.282)

  • 우리는 행운과 우연한 성공에 의존하는 프로그래밍이 아닌 의도적으로 하는 프로그래밍 을 해야 한다.
  • 왜 코드가 망가졌는지 모르는 까닭은 애초에 코드가 왜 잘 돌아갔는지도 몰랐기 때문이다.
  • 문서화된 동작에만 의존하라, 그럴 수 없다면 추측을 문서로 상세히 남겨라.
  • 가정하지 말라. 증명하라.
  • 인터넷 검색으로 찾은 첫 번째 답에서 코드를 복사해 올 때 여러분과 동일한 상황이라고 확신하는가? 아니면 의미는 신경쓰지 않고 그냥 따라 하는 "화물 숭배" 코드를 만들고 있나?
  • 잘 되는 듯한 답을 찾는 것과 올바른 답을 찾는 것은 다르다.
  • 확고한 사실에 근거하지 않은 가정은 어떤 프로젝트에서든 재앙의 근원이 된다.
  • 코드뿐 아니라 내가 세운 가정도 테스트해 보아야 한다. 어떤 일이든 추측만 하지 말고 실제로 시험해 보라.
  • 기존 코드가 앞으로 짤 코드를 지배하도록 놓아두지 말라. 더는 적절한 코드가 아니다 싶으면 어떤 코드라도 교체할 수 있다. 언제나 리팩토링할 자세가 되어 있어야 한다.

• 알고리즘의 속도 (p.291)

  • 코드의 실행 시간이 얼마나 될지 또는 메모리를 얼마나 사용할지 확실하지 않다면 직접 실행해보라.
  • 정확하게 시간을 재는 일이 어렵다면 코드 프로파일러 를 사용하여 알고리즘이 돌아갈 때 각 단계의 실행 횟수를 센 다음 입력값 크기별 실행 횟수를 그래프로 그려 보라.
  • 가장 빠른 알고리즘이 언제나 가장 좋은 알고리즘은 아니다.
  • "성급한 최적화"를 조심하라. 시간 투자 전 그 알고리즘이 정말로 병목인지 먼저 확인하는 것이 좋다.

• 리팩토링 (p.300)

  • 소프트웨어 개발은 "건축"보다 "정원 가꾸기"에 가깝다. (유기적인 활동)
  • 리팩토링은 잡초 제거나 갈퀴질처럼 위험하지 않은 작은 단계들을 밟는 일상 활동이다.
  • 소스 코드를 이곳저곳 변경하는 것은 굉장히 고통스러운 작업일 수도 있다. 많은 개발자들이 코드에 조금 개선할 부분이 있다는 이유만으로는 다시 돌아가서 코드 열기를 주저한다.
  • 일정의 압박은 리팩토링을 하지 않는 단골 핑계다.
  • 일찍 리팩토링하고, 자주 리팩토링하라. (단, 리팩토링할 시간을 일정에 확실히 포함해야 한다.)
  • 리팩토링의 본질은 재설계다.
    • 리팩토링과 기능 추가를 동시에 하지 말라.
    • 리팩토링을 시작하기 전 테스트가 있는지 먼저 확인하라.
    • 단계를 작게 나누어서 신중하게 작업하라.
  • 기대하는 수준에 못 미치는 코드를 발견하면, 고쳐라. 고통을 관리하라. 지금은 고통스러울지라도 앞으로 더욱 고통스러워질 것 같으면 지금 고치는 편이 낫다.

• 테스트로 코딩하기 (p.307)

  • 테스트는 버그를 찾기 위한 것이 아니다.
  • 테스트가 코드의 첫 번째 사용자다.
  • 명백한 테스트는 개발을 이끌어 나가는 데 도움이 된다. 하지만 나아갈 때마다 목적지를 떠올리지 않으면 계속 같은 자리만 빙빙 돌게 될 수도 있다.
  • 단위 테스트를 계약을 잘 지키는지 보는 테스트로 생각해야 한다.
    • 코드가 계약을 지키는지 확인
    • 코드로 표현된 계약의 의미가 우리가 생각한 것과 일치하는지 여부 확인
  • 테스트할 수 있도록 설계하라.
  • 로그 메시지는 반드시 규칙적이고 일고나된 형식이어야 한다. 프로그램의 처리 시간이나 프로그램이 택한 논리 경로를 추론하기 위해 로그를 자동으로 파싱하고 싶을 때가 있기 때문이다.
  • 테스트 코드를 다른 제품 코드와 마찬가지로 다뤄라. 결합도를 낮추고, 깨끗하고 견고하게 유지하라.
  • 테스트, 설계, 코딩, 이 모든 것이 프로그래밍이다.

• 속성 기반 테스트 (p.321)

  • 속성 : 코드에 존재하는 계약과 불변식
  • 속성 기반 테스트 : 코드에서 속성을 찾아내 자동화한 테스트
  • 역할
    • 문제가 발생하는 상황에 집중할 수 있게 해줌
    • 회귀 테스트
  • 속성 기반 테스트가 실패했다면 테스트 함수가 어떤 매개 변수를 사용했는지 알아낸 다음 그 값을 이용하여 별도의 단위 테스트를 정식으로 추가하는 것이 좋다.
  • 코드를 불변식과 계약이라는 관점으로 보면 데이터의 일관성을 해치는 함수를 찾기 수월해진다.

• 바깥에서는 안전에 주의하라 (p.331)

  • 해킹은 공격자의 지능이 높아서 일어나기보다 개발자의 부주의로 벌어진다.
  • 보안 원칙
    • 공격 표면을 최소화하라. (공격 표면 = 사용자와 서비스의 모든 접근 지점)
    • 최소 권한 원칙 (최소한의 권한만을 꼭 필요한 시간만큼만 제일 짧게 부여)
    • 안전한 기본값
    • 민감 정보를 암호화하라
    • 보안 업데이트를 적용하라

• 이름 짓기 (p.341)

  • 언어 자체의 문법에선 어느 쪽이든 상관없다고 하더라도 아무 것이나 쓰면 안 된다.
  • 프로그래밍 언어별 문화를 존중하라. (변수명, 표기법 등)
  • 반드시 팀의 모든 살마이 각 단어의 뜻을 알고 일관성 있게 사용해야 한다.
    • 짝 프로그래밍, 용어 사전 등의 방법을 통해 의사소통을 장려할 수 있다.
  • 잘못된 이름은 바로 고쳐라, 고칠 수 없다면 ETC 위반이다.

🤔 소감 및 생각

• 이 챕터의 내용처럼 '잘 되는 코드를 괜히 내가 리팩토링 하려고 했다가 더 오류가 나진 않을까?' 라는 생각때문에 더 나은 코드로 교체하기를 두려워했던 적이 많았고, 지금도 그렇다. 새로운 시스템을 개발할 때 TDD 기반으로 진행하여야 회귀테스트 등 리팩토링 후에도 동일하게 정상 동작함을 증명 가능하기 때문에 테스트 코드 작성이 더욱 더 중요함을 다시 느끼게 되었다.

🔍 새롭게 또는 다시 알게 된 내용

• 스트루프 효과 : 과제에 대한 반응 시간이 주의에 따라 달라지는 효과 또는 이러한 현상을 이용하는 검사

2 주차

화, 수 | Assignment #10

• 📚 6장. 동시성
• ✔️ TIL

6장. 동시성

📘 책에서 기억하고 싶은 내용

• 동시성 : 둘 이상의 코드 조각이 실행될 때 동시에 실행중인 것처럼 행동하는 것

  • 실행 중에 코드의 다른 부분으로 실행을 전환할 수 있는 환경에서 코드를 구동해야 함

• 병렬성 : 실제로 동시에 실행되는 것

  • 두 가지 일을 동시에 할 수 있는 하드웨어가 필요함

• 시간적 결합 깨트리기 (p.243)

  • 애플리케이션의 작업 흐름을 모델화하고 분석하는 작업이 필요함
  • 활동 다이어그램 사용 시 동시에 수행할 수 있는데도 아직 동시에 하고 있지 않은 활동들을 찾아내서 병렬성 극대화 가능
  • 비교적 독립적인 부분 작업들은 병렬로 처리하여 결과를 합치면 효율성을 높일 수 있음

• 공유 상태는 틀린 상태 (p.249)

  • 코드에서 둘 이상이 파일, DB, 외부 서비스 등 어떤 리소스에 동시에 접근할 수 있다면 잠재적인 문제를 안고 있는 것
  • 불규칙한 실패는 동시성 문제인 경우가 많다.

• 액터와 프로세스 (p.258)

  • 액터 모델에서는 공유된 상태가 없기 때문에 동시성을 다루는 코드를 쓸 필요가 없다. 또한, 액터가 수신하는 메시지에 따라 알아서 실행되기 떄문에 명시적으로 처음부터 끝까지 무엇을 하라는 코드도 쓸 필요가 없다.
  • 다른 대부분의 언어에도 액터 구현이 있으니, 동시에 실행되는 작업을 구현할 떄 액터를 사용하라.

• 칠판 (p.266)

  • 칠판 : 형사가 수사 시 칠판을 이용하는 것과 같이 일종의 자유방임주의적 동시성을 의미
  • 카프카나 NATS 같은 메시징 시스템은 칠판으로도, 여러 액터를 실행하는 플랫폼으로도 사용할 수 있다.
    • 이벤트 로그의 형태로 영속성을 제공하고, 패턴 매칭 형태로 메시지를 가져오는 것도 지원함
  • 아키텍처에서 MSA, 액터, 칠판 등을 사용하면 애플리케이션에서 생길 수 있는 모든 종류의 동시성 문제를 예방할 수 있지만 비용이 수반된다. 이때는 메시지 형식 및 API를 모아두는 중앙 저장소를 운영하면 도움이 될 것이다.
    • 맞춰야 하는 구성 요소 수가 더 많기 때문에 배포 및 관리가 까다롭지만 잘게 쪼개진 시스템 덕에 개별 액터만 교체하여 업데이트가 가능하게 한다.
  • 특정한 비즈니스 작업 처리를 시작할 때 고유한 추적 아이디를 만들어 붙이고, 추후 해당 작업에 관여하는 모든 액터로 아이디를 전파하면 로그를 분석하여 일어난 일을 재구성해볼 수 있다.

🤔 소감 및 생각

• 부끄럽지만 아직 메시징 시스템을 제대로 사용해본 적이 없는데, 추후 따로 공부해서 동시성을 고려하는 시스템을 잘 개발할 수 있도록 해야겠다고 생각했다.
• 공부는 하면 할수록 내가 얼마나 부족한 사람인지 증명하는 것만 같다. 😢

🔍 새롭게 또는 다시 알게 된 내용

• 파이버 : 스레드보다 더 가벼운 실행 흐름을 만드는 도구

2 주차

토 | Assignment #08

• 📚 5장. 구부러지거나 부러지거나
• ✔️ TIL

5장. 구부러지거나 부러지거나

📘 책에서 기억하고 싶은 내용

• 결합도 줄이기 (p.182)

  • 우리가 어떤 것 하나만을 골라내려고 해도, 그거싱 우주의 다른 모든 것과 얽혀 있음을 깨닫게 된다. - 존 뮤어
  • 열차 사고 : 모든 메소드나 속성들이 서로 연결되어 있는 상황
  • 디미터(LoD) 법칙
    • 클래스 C에 정의된 메소드가 다음 목록에 속하는 것만 사용 가능
      • C의 다른 인스턴스 메소드
      • 메소드의 매개 변수
      • 스택이나 힙에 자신이 생성하는 객체의 메소드
      • 전역 변수
    • 현재는 의미가 많이 퇴색되었으나 기반 원칙 자체는 유효하다.
  • 전역 변수를 추가하는 것은 전체 메소드에 매개 변수를 하나씩 추가하는 것과 같다.
  • 싱글톤 객체, 외부 리스소를 포함한 전역 변수 및 데이터는 결합도를 높인다.
  • 상속도 결국 결합도를 높이는 것과 같다.

• 실세계를 갖고 저글링하기 (p.193)

  • 이벤트 : 무언가 (새로운)정보가 있다는 것을 의미
  • 이벤트 기반 애플리케이션 개발 전략
    • 유한 상태 기계
      • 상태 기계는 이벤트를 어떻게 처리할지 정의한 명세, 이벤트와 관련된 모든 문제를 해결하지는 못한다.
    • 감시자(Observer) 패턴
      • 이벤트를 발생시키는 "감시 대상"과 이벤트에 관심이 있는 클라이언트인 "감시자"로 이루어진다.
      • 모든 감시자가 감시 대상에 등록되어야 하기 때문에 결합이 생긴다.
      • 또한, 감시 대상이 콜백을 직접 호출하도록 구현하기 때문에 이 부분이 성능 병목이 될 수 있다.
      • 감시자 패턴의 문제는 "게시-구독"으로 해결한다.
    • 게시-구독
      • 감시자 패턴을 일반화한 것으로, 감시자 모델의 문제(결합도, 성능)를 해결한다.
      • 게시-구독 모델을 많이 사용하는 시스템의 경우 현재 어떤 일이 벌어지고 있는지 파악하기가 힘들다는 것이 단점이다.
    • 반응형 프로그래밍과 스트림
    • 이벤트를 중심으로 공들여 만든 코드는 일직선으로 수행되는 코드보다 더 잘 반응하고 결합도가 낮다.

• 변환 프로그래밍 (p.207)

  • 언어에서 파이프라인을 지원하지 않을 경우 아래와 같이 사용 가능하다.

        const content = File.read(file_name);
         const lines = find_matching_lines(content, pattern);
        const result = truncate_lines(lines);

  • 변환 사이에 값을 절대 날것으로 넘기지 않고, Wrapper 역할을 하는 자료 구조나 타입으로 값을 싸서 넘겨야 한다.

• 상속세 (p.224)

  • 상속은 타입을 조합하는 방법이라고 설명하는 시뮬라 방식 은 C++ 나 Java 같은 언어가 계승했다.
  • 상속은 동작을 다양하게 구성하는 방법이라고 설명하는 스몰토크 방식 은 Ruby 나 JavaScript 에서 찾아볼 수 있다.
  • 상속도 일종의 결합이고, 다중 상속은 더 심한 문제를 일으킨다.
  • 상속을 대체하는 방법
    • 인터페이스와 프로토콜
      • 이들을 타입으로 사용할 수도 있고, 해당 인터페이스를 구현하는 클래스라면 무엇이든 그 타입과 호환되기 때문에 강력하다.
      • 다형성은 인터페이스로 표현하는 것이 좋다.
    • 위임(Delegation)
      • 멤버변수에 실제 상속받아 구현하려 했던 객체를 담고, 이를 사용
    • 믹스인과 트레이트
      • 바깥세상에 노출해야 하는 메소드들을 일일이 위임해야 하는 위임의 단점을 보완한 방안
      • 플래그를 이용하여 모든 검증 상황을 관리하는 것이 아닌 믹스인을 사용하여 각 상황에 맞는 전문호된 클래스를 만드는 것이 더 낫다.
  • 상속이 답인 경우는 드물다.

• 설정 (p.236)

  • 외부 설정으로 애플리케이션을 조정할 수 있게 하라.
    • 인증 정보, 로그 레벨과 저장 위치, 포트/IP, 라이선스 키 등
  • 설정 정보를 전역에서 접근할 수 있도록 하는 것이 아닌 API 뒤로 숨기는 서비스형 설정을 사용하라.
  • 설정 정보를 바꾸기 위해 코드 빌드가 필요해서는 안 된다.
  • 외부 설정을 사용하지 않는다면 코드는 적응성이나 유연성을 어느 정도 포기해야만 한다.
  • 나의 프로젝트가, 나의 경력이 도도의 전철을 밟지 않도록 하라.

🤔 소감 및 생각

• 이번 챕터를 읽으며 반응형 프로그래밍을 처음 배울 때 책에서 말하는 데이터를 거대한 강으로, 흐름으로 생각하라 라는 개념이 쉽지 않았었던 기억이 났다(지금도 사실 쉽지 않다). 그 당시에는 개념은 이해가 되어도 막상 코드를 작성하려니 막막하였고, 러닝커브가 크다는 사실에 잠깐 절망에 빠지기도 했다. 하지만 적응하며 답답했던 시기가 지나고 나니 반응형 프로그래밍의 장점을 점점 이해하게 됐는데, 이처럼 새로운 개념에 지속적으로 적응하려는 노력을 해야겠다고 생각하였다.
• WebFilter 등 일부 인터페이스 및 클래스를 상속받아 커스터마이징에 사용할 때 상속이 당연하다고 생각했었는데, 이번 챕터를 읽으며 그 생각이 바뀌게 되는 계기가 되었다. 앞으로 클래스 상속 전에 다른 방안도 고려해볼 수 있도록 노력해야겠다.

🔍 새롭게 또는 다시 알게 된 내용

• 애너그램 : 단어의 철자 순서를 바꾸어서 만든 다른 단어
• 믹스인 : 다른 클래스의 부모클래스가 되지 않으면서 다른 클래스에서 사용할 수 있는 메소드를 포함하는 클래스

1 주차

목 | Assignment #06

• 📚 4장. 실용주의 편집증
• ✔️ TIL

4장. 실용주의 편집증

📘 책에서 기억하고 싶은 내용

• 완벽한 소프트웨어는 만들 수 없고, 이를 인정하자

• 실용주의 프로그래머는 자기 자신도 완벽한 코드를 작성할 수 없음을 알기 때문에 자신의 실수에 대한 방어책을 마련한다.

• 계약에 의한 설계 (p.147)

  루틴과 호출자 코드 간의 계약

  • 만약 호출자가 루틴의 모든 선행 조건을 충족한다면 해당 루틴은 종료 시 모든 후행 조건과 불변식이 참이되는 것을 보장한다.
  • 어느 한 쪽이라도 계약 내용을 지키지 못할 경우 양측이 동의한 내용에 따라 해결 방안이 실행된다.

  • DBC(Design By Contract) : 프로그램의 정확성을 보장하기 위해 소프트웨어 모듈의 관리와 책임을 문서화하고 합의하는 데에 초점을 맞추며, 문서화하고 검증하는 것이 핵심

    • 선행 조건 : 루틴 요구사항, 루틴이 호출되기 전에 참이어야 하는 것
    • 후행 조건 : 루틴이 완료되었을 때의 상태, 루틴이 할 것이라고 보장하는 것
    • 클래스 불변식 : 루틴 종료 후 불변속성 보장

  • 게으름뱅이 코드 : 시작하기 전에 자신이 수용할 것은 엄격하게 확인하고, 내어 줄 것에 대해서는 최소한도를 약속하는 것

  • 의미론적 불변식 : 어겨서는 안 되는 고정된 규칙인 요구 사항 표현 고정된 규칙과 변동 가능성이 큰 정책을 혼동하지 말아야 함

  • TDD를 하고 있음에도 DBC는 필요하다.

  • 코드 작성 전 유효 입력 범위, 경계 조건, 선후행 조건 등을 나열하는 것만으로도 구현에 도움이 되며, 결국 DBC는 설계 기법이다.

  • 선행 조건은 명시적으로 검증해야 할 매개 변수가 하나라도 있다면 호출자에서 검증을 수행해야 한다.

• 죽은 프로그램은 거짓말을 하지 않는다 (p.158)

  • 그런 일은 절대 일어날 리 없어. 라는 사고에 빠지기는 쉽다.
  • 모든 오류는 정보를 준다.
  • 죽은 프로그램이 끼치는 피해는 이상한 상태의 프로그램이 끼치는 피해보다 훨씬 적다.

• 단정적 프로그래밍 (p.162)

  • 진짜 오류 처리를 해야 하는 곳에 단정을 대신 사용하지 말라.
  • 단정문에 대한 오해
    • 성능 저하
    • 버그가 있을 때만 단정 검사가 실패함
    • 릴리즈 이후에는 더 이상 단정이 필요하지 않음
    • 단정문은 디버깅 도구임

• 리소스 사용의 균형 (p.167)

  • 자신이 시작한 것은 자신이 끝내라 (내가 자원을 사용하기 시작했음 내가 해제해야 함)
  • try-with-resouce 과 같은 구문을 사용할 수 있다명 해당 범위에서만 자원이 사용되도록 해야 한다.
  • 리소스를 할당한 순서의 역순으로 해제하라. (참조가 망가질 경우를 대비)
  • 코드의 여러 곳에서 동일한 구성의 리소스들을 할당하는 경우에는 언제나 같은 순서로 할당해야 교착 가능성을 줄일 수 있다.
  • 리소스를 할당하는 것이 언제나 그 리소스를 해제할 책임까지 져야 한다.
  • 리소스를 클래스 안에 캡슐화 하는 것이 유리하다. (GC가 수행되며 리소스가 해제됨)
  • 자료구조에서 최상위 구조의 메모리 할당 해제 방안
    • 최상위 구조가 하위 구조들을 해제할 책임을 지고, 하위 구조가 다시 재귀적으로 해제할 책임을 짐
    • 최상위 구조만 할당 해제, 최상위 구조가 참조하던 하위 구조들은 연결이 끊어져 다른 곳에서 참조하지 않으면 사용되지 않음
    • 최상위 구조가 하나라도 하위 구조를 가지고 있으면 자신의 할당 해제를 거부함

• 헤드라이트를 앞서가지 말라 (p.177)

  • 더 진행하기 전에 피드백을 확인하고 조정하라.
  • 볼 수 있는 미래까지만 고려하라.
  • 미래가 어떤 모습일지 더 많이 예측하려 할수록 틀릴 가능성은 계속 높아질 것이다.

🤔 소감 및 생각

• DBC 는 처음 접해보는 개념이었는데 DBC 가 가지고 있는 철학이나 방법 같은 부분이 새로웠던 것 같다.
• 여러 공부를 병행하려니 체력적으로 점점 뒷받침해주지 않는 것 같다.. 체력을 키워야겠다고 생각했다.

🔍 새롭게 또는 다시 알게 된 내용

• 불변속성 : 어떤 객체의 상태가 프로그래머의 의도에 맞게 잘 정의되어 있다고 판단할 수 있는 기준을 제공하는 속성

1 주차

수 | Assignment #05

• 📚 3장. 기본 도구
• ✔️ TIL

3장. 기본 도구

📘 책에서 기억하고 싶은 내용

• 일반 텍스트의 힘 (p.105)

  • XML, HTML, JSON, YAML 및 HTTP, SMTP, IMAP 등 인터넷에서 사용되는 핵심 프로토콜도 대부분 일반 텍스트다.

• 셸 가지고 놀기 (p.110)

  • 모든 작업을 GUI로만 하면 내가 가진 환경의 능력을 전부 이용할 수 없다.
  • GUI 환경의 기능은 일반적으로 설계자가 의도한 범위를 넘어설 수 없다.
  • 색깔 조합 설정, 프롬프트 설정, 별칭과 셸 함수, 명령어 자동 완성을 통하여 개발자 편의성 증대가 가능하다.

• 파워 에디팅 (p.114)

  • 에디터를 사용하며 특정 행위를 반복한다면 개선하고, 개선한 방법을 의식적으로 사용하도록 하라.
  • 마우스 없이 키보드를 사용하는 방법을 연습하다 보면 처음엔 불편하지만 생산성을 크게 높일 수 있다.

• 버전 관리 (p.119)

  • 공유 디렉토리, 네트워크 드라이브, 클라우드는 지속 가능한 버전 관리 시스템이 아니다.
  • 혼자서 진행하는 경우나 나중에 버리기로 한 프로토타입일지라도 버전 관리가 필요하다.
  • 중앙 저장소를 두면 프로젝트 업무 흐름을 원활하게 해주는 수많은 확장 기능을 이용할 수 있다.

• 디버깅 (p.125)

  • 다른 사람의 버그를 발견하면 버그를 만들어 낸 범죄자를 비난하기보다 문제를 고치는 데에 집중해야 한다.
  • '하지만 정말 그럴 리가 없는데.'로 시작하는 생각의 흐름에 신경 세포 하나도 낭비하지 말라.
  • 디버깅할 때 근시안의 함정에 주의하라, 실제 문제는 몇 단계 떨어져 있고 또 다른 여러 가지와 연관되어 있을 확률이 다분하다. 특정한 증상만 고치려고 하지 말고, 항상 문제의 근본적인 원인을 찾으려고 노력하라.
  • 컴파일러의 경고 수준을 최고로 높게 맞춰 컴퓨터가 대신 찾아 줄 수 있는 문제를 찾느라 시간을 허비하지 않도록 한다.
  • 인공적인 테스트는 애플리케이션을 충분히 테스트하지 못하기 때문에 경계 조건과 실제 최종 사용자의 사용 패턴 모두 철저히 테스트해야 한다.
  • 코드를 고치기 전 실패하는 테스트부터 생성한다.
  • 매우 긴 Stack Trace를 봐야 할 때는 이진 분할을 이용한다.
    • 중간 즈음에서 스택 프레임을 하나 골라 해당 시점에 값이 정상인지 확인하고, 아니라면 이를 다시 반복한다.
    • 문제가 발생한 릴리즈 버전을 찾을 때도 이러한 방식을 사용할 수 있지만 VCS가 테스트 결과에 따라 문제가 발생한 릴리스를 찾게 할 수도 있다.
  • 트레이싱 구문 : 도달 여부 등을 알기 위해 화면 혹은 파일에 출력하는 진단용 메시지
    • 메시지를 자동으로 분석해야 할 수도 있으므로 규칙적이고 일관된 형식이어야 한다.
  • 누군가에게 코드를 설명하다 문제점을 찾게 될 수도 있다.
  • 단 하나만을 변경했음에도 시스템이 작동을 멈춘다면 아무 관련 없어도 변경한 그 하나에 책임이 있다.
  • 놀라운 버그를 발견했을 때 고치는 것을 넘어 왜 더 일찍 발견되지 않았을지 고민해야 한다.
    • 이것과 유사한 버그가 있을 법한 다른 코드가 있는지도 확인해야 한다.
  • 버그가 누군가의 잘못된 가정으로 발생했다면 이 문제를 전체 팀과 함께 토론하라.

• 텍스트 처리 (p.139)

  • 텍스트 처리 언어를 익혀 유틸리티, 프로토타입 등에 활용해보자. (전통적인 언어를 사용했을 때보다 시간 단축이 가능하다.)

• 엔지니어링 일지 (p.142)

  • 파일이나 위키 말고 종이를 사용하여 엔지니어링 일지를 작성하라.
    • 진행중인 작업과 직접적인 관계가 없는 발상을 쌓아 놓을 수 있다.

🤔 소감 및 생각

• 당연하지만 지키기 어려웠던 내용도 있고, 새로운 내용도 있어 읽는 데에 지루하지 않은 것 같다. 디버깅 관련 내용이 가장 인상 깊었다.

🔍 새롭게 또는 다시 알게 된 내용

• NONE

1 주차

화 | Assignment #04

• 📚 복습
• ✔️ 미션 Mission (1) : 최애 북틸(Book-TIL) 3개 선정하기

Mission(1)

나의 최애 TIL

1. https://github.com/shinpanda/TIL/blob/main/BOOKS/실용주의프로그래머/TIL%232.md

2. https://nomadcoders.co/community/thread/3705

3. https://cindybaby.notion.site/DAY-03-04-5b811fbb19ab4683aad52b66b47e14fc

선정 이유 및 소감

• 세 개의 글 모두 책의 내용이 정리가 잘 되어 있고, 매일 책을 읽으신 뒤 깊이 있는 견해나 진심을 소감으로 모두 표현하신 부분이 좋았다.
• 아무래도 공개적으로 글을 작성하다 보니 소감을 매우 자유롭게 쓰지는 못하는 것 같았는데, 위 글을 보며 나도 더 자유롭게 써보아야겠다는 생각이 들었다. 그리고 같은 책을 각자 다르게 정리한 부분이 재밌었던 것 같다.