클린 코드 독서일지 - Day 26

스레드 코드 테스트하기

말이 안 되는 실패는 잠정적인 스레드 문제로 취급하라

스레드 코드의 버그는 실패를 재현하기가 어려워, 일회성 문제로 치부되곤 함
-> 시스템 실패를 일회성이라 치부하지 말 것.

다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자

스레드 환경 밖에서 코드가 제대로 도는지 먼저 확인하기
-> 스레드가 호출하는 POJO를 만들어서 테스트 가능

다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 스레드 코드를 구현하라

다양한 설정으로 실행하기 쉽게 구현하기

다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라

스레드 개수를 조율하기 쉽게 코드를 구현, 프로그램이 돌아가는 도중에 스레드 개수를 변경하는 방법이나 프로그램 스스로 스레드 개수를 조율하는 코드도 고려하기

프로세서 수보다 많은 스레드를 돌려보라

프로세서 수보다 많은 스레드를 돌려서 스와핑을 일으켜 보기
-> 스와핑이 잦을수록 임계영역을 빼먹은 코드나 데드락을 일으키는 코드를 찾기 쉬워짐.

다른 플랫폼에서 돌려보라

다중 스레드 코드는 플랫폼에 따라 다르게 돌아갈 수 있으므로, 코드가 돌아갈 가능성이 있는 플랫폼 전부에서 테스트를 수행하기

코드에 보조 코드를 넣어 돌려라. 강제로 실패를 일으키게 해보라

보조 코드를 추가해 코드가 실행되는 순서를 바꿔 가면 드물게 발생하는 스레드 코드 오류를 좀 더 자주 일으킬 수 있다.

• 직접 wait(), sleep(), yield() 함수를 추가해서 구현 가능 - 보조 코드를 삽입할 적정 위치를 찾기 어렵고 오류가 무작위적이라는 단점
• AOF, CGLIB, ASM 등 도구를 이용하여 보조 코드를 자동으로 추가 가능

좋은 테스트 케이스와 흔들기 기법(스레드를 매번 다른 순서로 실행하게 해주는 것)은 오류가 드러날 확률을 크게 높여준다.

결론

다중 스레드 코드는 올바로 구현하기 어려우므로, 앞서 말한 방식들을 활용해 각별히 깨끗하게 코드를 짠다.