건실성실착실 3실 청년!

Thread 관련된 문제는 항상 강조하는 게 "버그 잡기 힘들다." 입니다. 
Thread 관련 얘기 중 첫번 째로 Thread safe에 대해서 시작해보겠습니다.

1. 원자성

원자성이란 CPU가 처리하는 하나의 단일 연산을 말합니다.
int a=1; 과 같은 코드는 원자성입니다.
int a=1+1; 도 원자성입니다.
그러나
a++;은 원자성이 아닙니다.
a++은 a= a+1 과 같은 의미인데, (a값을 읽는다) + (읽은 값에 1을 더해서 a에 대입한다.) 라는 2개의 원자성 연산의 조합입니다.
원자성을 가진 연산이 2개 이상 있을 때 그것은 원자성이 보장되지 않습니다. 아래의 코드를 실행시켜보세요.

public class AtomicTest {
 private int a=0;
 public int incrementAndGet(){
  return a++;
 }
 public static void main(String[] args) {
  final AtomicTest test = new AtomicTest();
  for (int i = 0; i < 100; i++) {
   new Thread(){
    public void run(){
     for (int j = 0; j < 1000; j++) {
      System.out.println(test.incrementAndGet());
     }
    }
   }.start();
  }
 }
}

100개의 Thread가 1000번씩 증가시켰으면 100,000이 나와야 할 것 같지만 보통 그 보다 좀 덜 나옵니다.
초기값이 0인 a에 대해 a++연산을 Thread A, B가 처리할 경우,
1. A Thread가 a의 값을 읽음. (a=0)
2. B Thread가 a의 값을 읽음. (a=0)
3. A Thread가 a의 값 계산 후 대입. (a=0+1 = 1);
4. B Thread가 a의 값 계산 후 대입. (a=0+1 = 1);
와 같이 흘러가면 결국 a=1이 됩니다. 두번 돌았으니 2가 되어야 하지만 말입니다.

원자성 연산의 조합은 절대 원자성 연산이 아닙니다.



2. Thread safe

Thread safe란 여러 개의 쓰레드에서 동시에 호출해도 문제가 되지 않는 클래스입니다. Thread safe에 대해서 정확히 알려면, 변수의 scope과 자바의 메모리 관리 등에 대해서 좀 알아야 합니다. 자바 기초 책에 나오는 클래스 변수, 지역 변수 등을 명확히 이해해야 하며, 메인 메모리와 워킹 메모리에 대해서 대략적인 가닥은 잡으셔야 합니다.

Thread safe 하게 프로그램을 만들려면 일반적으로 synchronized 구문을 씁니다.
StringBuffer 와 StringBuilder, Vector 와 ArrayList, Hashtable과 HashMap 같은 것들이 synchronized가 걸려있고 안걸려 있고 정도의 차이만을 보이는 대표적인 클래스들입니다.(물론, 그게 전부는 아니지만 핵심입니다.)

StringBuffer, Vector, Hashtable 등이 자바 초기에 등장한 애들입니다. 얘들은 synchronized가 걸려있는 대표적인 애들입니다. synchronized가 걸리면 안 걸린 것에 비해서 당연히 느립니다. 즉, 정말 synchronized 가 걸려있어야 하는지를 보고 그렇다면 그런 애들을 쓰면 됩니다.

먼저 StringBuffer는 일반적으로 쓸 일이 없습니다. 여러 개의 Thread에서 하나의 String을 조합하는 것은 일반적으로 굉장히 이상한 일입니다. 다만 StringBuffer 자체를 인자로 받는 라이브러리를 쓸 때는 어쩔 수 없지만 일반적으로는 쓸 일이 없습니다. 보통은 StringBuilder를 사용하면 됩니다.

Vector와 Hashtable 등을 쓸 수는 있지만, iterator 등을 돌 때는 주의해야 합니다. iterator를 돌면서 추가 삭제를 하는 것은 위험합니다. 다음 프로그램은 에러를 발생시킵니다.(쓰레드 관련 프로그램이 늘 그렇듯... 안 발생할 수도 있습니다.)

public class VectorIteratorTest {
 public static void main(String[] args) {
  final Vector<Integer> a = new Vector<Integer>();
  for (int i = 0; i < 100; i++) {
   a.add(i);
  }
  
  new Thread(){
   public void run(){
    for (int i = 100; i < 1000; i++) {
     a.add(i);
    }
   }
  }.start();
  
  for (Integer integer : a) {
   System.out.println(integer);
  }
 }
}

Exception in thread "main" java.util.ConcurrentModificationException
 at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
 at java.util.AbstractList$Itr.next(AbstractList.java:343)
 at thread.VectorIteratorTest.main(VectorIteratorTest.java:24)

요런일이 생깁니다. Thread safe 하기 때문에 문제가 안 될 것 같지만, iterator 부분이 문제 입니다. 일단 요기 를 읽어보시고...
전부 단일 연산인 것 같지만 iterator를 도는 게 단일 연산인 것은 아니기 때문에 생기는 문제입니다. 저걸 단일 연산으로 맞추고 싶다면 iterator 바깥부분을 synchronized (a) { } 로 감싸주어야 합니다.


3. 잘못 쓰기 쉬운 라이브러리

date format을 처리하기 위해 SimpleDateFormat 클래스를 씁니다. 이놈은 thread safe 하지 않습니다. new 로 매번 생성하거나 생성된 객체를 clone 떠서 사용하기를 권장합니다.

Jaxb Marshaller는 xsd에서 나온 bean 객체를 이용하여 xml을 만들어낼 때 쓰는 놈인데, 이 놈도 thread safe 하지 않습니다. 게다가 이놈은 생성비용도 굉장히 비쌉니다. 생성 과정을 전부 살펴보진 않아서 정확히는 모르겠지만, 동시에 수백개를 생성하게 되면 생성 속도가 몇 초 단위로 나오더군요. 이건 pool을 사용해서 처리했습니다. jakarta common에 있는 common-pool 을 사용했습니다.

Servlet이나 JSP는 Flyweight 로 구현되었습니다. 즉 instance가 1개이기 때문에 동시에 여러 thread가 접근하면 문제가 생길 수 있습니다. 흔히 디비에서 조회한 결과를 멤버 변수에 저장하는 실수를 범하곤 하는데, 인스턴스가 1개이기 때문에 엉뚱한 사람이 그 결과를 보게 될 수 있습니다. 즉 Servlet이나 JSP는 Thread safe하게 제작되어야 합니다.!

다음 예제는 잘못된 서블릿입니다.

public class WrongServlet extends HttpServlet {

private static final long serialVersionUID = 1L;

    private String userName;

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

fillUserName(request);

response.getWriter().write(userName);

}

private void fillUserName(HttpServletRequest request) {

userName = (String) request.getSession().getAttribute("USER_NAME");

}

}

여러 개의 request가 들어오면 A thread가 set한 userName을 B thread가 읽어 들일 수 있습니다. 

4. Thread 관련된 것은 꼭 테스트를!!

Thread에 관련된 문제는 말씀드렸다시피 잘못 짜도 일반적으로 발생하지 않습니다. 어느 순간 발생하기도 하기 때문에 잡아내기가 정말 힘듭니다. 결과의 정합성에 대해서 "Thread 차원에서" 테스트를 반드시 거치기 바랍니다.

언젠가 Lock에 대해서 다룰 예정인데, 역시 테스트가 굉장히 중요합니다. lock 관련 문제는 잘 나가다가 어느 순간 뻗어버리는 일을 유발할 수 있습니다. 자세한 건 다음에...

프로그램에서는 데이터를 다룰 일 들이 참 많습니다. 필요에 따라 적절한 데이터 타입을 선언하는 게 매우 중요할 수 있습니다.

1. 모여야만 의미가 있는 것은 클래스로 만들자.

위도와 경도 데이터가 있다고 칩시다. 이는 어떤 위치을 표현하기 위한 것인데, 위도만으로도 경도만으로도 의미가 없습니다. 게다가 위도와 경도는 생김새도 매우 비슷합니다.(float이나 BigDecimal 등으로 표현 가능한 값들입니다.) 즉, 바꿔 쓰는 실수를 하기가 쉬운 경우입니다.
따로 따로 의미를 가질 수 없는 경우는 이런 데이터를 담을 수 있는 클래스를 별도로 만드는 게 좋습니다.

대략 다음과 같은 클래스가 정의가 될 겁니다.

import java.math.BigDecimal;

public final class Location {
 private final BigDecimal lat; //위도
 private final BigDecimal lng;  //경도

 public Location (BigDecimal lat, BigDecimal lng) {
  this.lat = lat;
  this.lng = lng;
 }

 public BigDecimal getLat() {
  return lat;
 }

 public BigDecimal getLng() {
  return lng;
 }
}

이렇게 만들면 따로 따로 쓰는 것보다 훨씬 안전합니다.

아래와 같은 함수 호출 스택을 타고 처리하는 과정이 있다고 가정합시다. 아래에서 Request 클래스는 lat과 lng의 최초값을 가지는 클래스라고 칩니다. HttpServletRequest 같은 걸 생각하시면 됩니다.
foo1 (Request req) -> foo2 (BigDecimal lat, BigDecimal lng) ->  ... -> fooN (BigDecimal lat, BigDecimal lng)

fooN 에서 lat과 lng이 바뀐 것을 발견했습니다. 과연 어디서 잘못된 것일까요? foo1 부터 fooN까지 다 뒤져봐야 합니다. 그러나, 함수가 다음과 같이 되어있다고 가정하면 얘기가 다릅니다.

foo1 (Request req) -> foo2 (Location point)  -> ...-> fooN (Location point)

fooN에서 잘못되었다면,foo1에서 Location 클래스를 만들 때 잘못 만들었거나 fooN에서 거꾸로 받아썼거나 둘 중 하나 입니다. (물론 중간에 Location 객체를 이상하게 만들어 내서 인자를 바꿔서 전달하는 것도 가능은 하지만 별로 현실적인 얘기는 아닙니다.)

즉, 프로그램이 잘못되었을 때 점검해야 할 포인트가 확 줄어듭니다.

이런 데이터 클래스를 만들 때는 다음 사항에 주의해야 합니다.

1. hashCode와 equals 구현이 필요한 지 고려해야 합니다.
HashMap이나 캐쉬 등에서 키로 사용될 여지가 있을 경우 구현해야 합니다. 이클립스의 기능을 이용하면 쉽습니다. 소스에서 오른쪽 클릭 -> Source -> Generate hashCode and equals  를 누르면 손 코딩 안해도 됩니다.

2. Serializable을 고려해야 합니다.
일반적인 데이터 객체는 하드디스크나 디비에 저장되거나 외부와 통신에 사용될 여지가 있습니다. 이럴 경우 Serializable을 구현해주어야 합니다. 아...Serializable은 한번 꼭 정리해야 할 것 같은데... 나중에 정리되면 링크 달겠습니다.ㅜㅜ

3. Cloneable을 고려해야 합니다.
어떤 데이터 객체는 복사되어 값이 살짝 수정되어 쓰인다거나 할 일이 있습니다. 또는 Prototype 패턴으로 객체가 생성되는 케이스도 있을 수 있습니다. 자세한 것은 요기를 참고해주세요.^^

4. 가능하면 Immutable로 만드는 게 좋습니다.
이건 요기를 참고해주세요.  

5. toString 을 반드시 구현하세요.
예제는 코드가 길어져서 생략했지만, 로그 등을 찍을 때 toString 을 구현하는 게 매우 좋습니다. 

2. Map 이나 List 등 Container 사용을 자제하자.

위와 같은 Location을 맵으로 만들면 다음과 같이 될 겁니다. 아래에서 request는 대충 뭔가 요청을 담고 있는 클래스의 인스턴스라고 칩니다.

Map<String, BigDecimal> location = new HashMap<String, BigDecimal>();
location.put("lat" , request.getParameter("lat"));
location.put("lng" , request.getParameter("lng"));

조금 전에 언급한 사항 들이 대부분 해결되었습니다. hashCode나 equals는 HashMap이 알아서 해줄 것이고, Serializable도 해결되었고, Cloneable도 해결되었습니다.(Cloneable 은 변수 타입을 Map 이 아니라 HashMap으로 하면 됩니다.)
Immutable 문제만 빼고는 깔끔하게 해결된 듯하지만 위와 같은 코드는 바람직하지 않습니다.

1. 데이터 클래스는 변경이 용이합니다.
기존의 Location 클래스에 주소 정보까지 넣는 걸로 바꾸려고 합니다. 시도/구군/동면 등의 정보를 넣으려고 하면 Location 객체를 쓸 경우 Location 객체 안에서만 바꿔주면 됩니다.(위와 같은 경우 Location 클래스의 Constructor에서 주소정보를 가져오는 부분을 추가하고 각각의 단위 주소에 대해서 getter 들을 만들어 주면 됩니다.)  하지만 Map을 쓸 경우 저렇게 만들어지는 클라이언트 코드를 전부 찾아서 바꿔야 합니다.
이것보다 더 큰 문제는 특정 필드를 제거할 때 생깁니다. 필드를 제거하게 되면 클래스에서는 멤버 변수 1개와 getter 1개 정도 제거하면 될 것이고, 제거된 함수를 쓰는 부분이 어딘지는 금방 알아낼 수 있습니다.(이클립스가 다 결켜줍니다.^^ compile 에러니까요.)
하지만 Map을 쓰면 ............................ 그냥 제거하지 마십시오..........

2. 데이터 클래스는 에러를 더 빨리 잡아낼 수 있습니다.
각각의 필드에 대해서 명확한 getter 메쏘드가 존재합니다. 하지만 Map을 쓰게 되면, get("lat") 과 같이 인자로 던져줘야 하는데 인자가 String이므로 오타가 나더라도 프로그램 실행을 해봐야 알 수 있습니다. Compile 타임에 에러를 잡아낼 수 있는 것과 Runtime에 에러를 잡아낼 수 있는 것의 차이가 생깁니다.

3. Map은 데이터의 일관성을 보장해 주지 않습니다.
Map은 <키, 값> 구조이므로 상황에 전혀 적절치 않는 데이터가 들어가는 것도 허용합니다. 위와 같은 코드에 location.put("owner", new BigDecial("8001011234567)); 과 같이 그 위치의 건물에 대한 주인의 주민번호를 BigDecimal로 표현한 이상한 값도 넣을 수 있습니다. 그나마 generic이 있기 때문에 이렇지 generic마저 없었으면... 매우 끔찍한 사태가 발생할 수도 있습니다.
또, 상황에 따라 get("뭐시기")를 했을 때 있을 수도 없을 수도 있습니다.반드시 뭔가 들어가 있다는 것을 보장해주지 않습니다. 이에 반해 데이터 클래스를 사용하면 Constructor에서 유효성 검사를 할 수 있습니다.

4. 속도도 느려지고 메모리 낭비가 생깁니다.
Map에서 데이터를 뽑는 게 결코 데이터 클래스의 getter보다 빠를 수 없고, Map은 어떤 식으로든 성능을 위해서 일단 데이터 클래스보다 더 많은 메모리를 확보합니다.


이보다 더 황당한 다음과 같은 코드도 있습니다.

List<BigDecimal> location = new ArrayList<BigDecimal>();
location.add(request.getParameter("lat"));
location.add(request.getParameter("lng"));

0번째 값은 위도 1번째 값은 경도로 쓰는 겁니다. 절대...절대.. 이러지 마십시오..

Container는 일반적으로 generic을 사용해 표현이 가능한데 <String> 과 같이 변수의 타입만 설정합니다. String은 사람의 이름을 표시할 수도 있고, 나라 이름을 표시할 수도 있습니다. Container를 사용할 때는 generic에 들어갈 것이 변수 타입이 아니라 표현할 데이터가 무엇인지를 정확하게 정의할 수 있을 때만 써야합니다.
즉, Map<String으로 표현된 사람이름, String으로 표현된 나라이름> 과 같이 generic 안의 타입뿐 아니라 타입이 의미하는 바가 정확히 무엇이다라고 정의할 수 있는 경우에만 Container를 사용하셔야 합니다.

3. 일반적으로 init함수는 틀렸다.

위와 같은 Location 클래스에서 주소 정보를 가져오는 로직이 들어갔다고 칩시다.(매우 무겁게도 구글 같은데에 통신을 해서 정보를 조회해야 할 겁니다.)
이런 경우 init 함수를 만들고 그 함수를 호출하면 구글에 통신해서 주소 정보를 세팅하도로 프로그램을 하는 경우가 많습니다. 하지만 주소 값이 반드시 필요하다면, Constructor에서 하면 됩니다.

주소값이 경우에 따라 필요하다면 다음 두 가지 해결 방법이 있습니다.

1. 주소에 관련된 getter에서 위치값이 설정되었는 지 확인합니다. 다음과 같은 코드가 가능합니다.

 private String address;
 public String getAddress() {
  if (address == null) {
   setAddressUsingHttp();
  }
  return address;
 }

 private void setAddressUsingHttp() {
     // 뭔가 통신해서 address라는 값을 세팅해주는 로직
 }

2. 또 다른 데이터 클래스를 만듭니다. 이 경우 기존의 Location 클래스를 Builder 처럼 이용하면 됩니다.

public final class Location{
 private final BigDecimal lat;
 private final BigDecimal lng;
 public Location(BigDecimal lat, BigDecimal lng) {
  this.lat = lat;
  this.lng = lng;
 }

 ... getter 들
 
 public LocationWithAddress getLocationWithAddress(){
  return new LocationWithAddress();
 }
 
 public class LocationWithAddress{
  private final String address;
  
  private LocationWithAddress(){
   // Constructor 안에서 http를 이용해서 lat, lng 으로 address를 읽어와서 세팅..
  }

  //Location 클래스에도 있는 method들..
  public BigDecimal getLat() {
   return lat;
  }
  public BigDecimal getLng() {
   return lng;
  }
 }
}


위와 같이 하면 LocationWithAddress라는 클래스의 생성자가 private 이므로 외부에서 생성이 불가능합니다. 오로지 Location을 통해서만 생성 가능하기 때문에 뭔가 잘못되었을 때 찾아내기가 쉽습니다.

보통의 init 함수는 대부분 Constructor에서 해결 가능한 것입니다. 게다가 일반적으로는 init을 호출하지 않으면 뭔가 문제가 생기도록 init 함수를 만드는데 이는 프로그램을 복잡하게 만들며,에러 가능성도 증대시킵니다.

그러면 servlet 이나 servlet filter 등에서도 init을 쓰는데 이것은 바른 사용일까요?
이 경우는 괜찮습니다. servlet이나 filter는 데이터형 클래스가 아닙니다. 즉, 사용자가 직접 Constructor를 호출한다거나 하는 식으로 instanciate 하지 않습니다. 게다가 모든 lifecycle이 톰캣 등에서 관리가 되기 때문에 이런 경우는 init이 호출되었는지 안 되었는지 등에 대해서 사용자가 신경쓸 게 없습니다.
Constructor는 직접 호출하지 않는 이상 상속이 안 됩니다. 따라서 상속 가능한 init 이라는 함수를 만들어서 쓰는 게 이런 경우는 훨씬 깔끔합니다.



정리하며..

사실 이번 글에서 하고 싶었던 얘기는 General한 프로그램과 Specific 한 프로그램에 대한 얘기였습니다. General 하다는 것은 위에서 얘기한 Map 같은 컨테이너를 쓰는 것과 같은 겁니다. 어징간하면 다 받아주는 거죠. Specific하다는 것은 위에서 Location 클래스와 같은 것을 만들어 쓴다는 것입니다. 딱 지정된 것만 받아들이는 겁니다.
일반적으로 General 함을 더 바람직한 것으로 생각하는 경향이 있는데, 결코 그렇지 않습니다. 기본적으로는 Specific한 케이스를 고려하고 거기서 더 general하게 풀어줄 수 있는 영역을 찾아내야 합니다.

대용량 서비스를 만드는 데 있어서 필요한 지식과 제가 간과해서 삽질했던 것들 등을 정리해보려고 합니다. java와 MySQL을 사용하였고, 가능하면 Mysql 에 국한되는 내용은 다루지 않을 생각입니다.


제 나름대로 좋은 프로그램을 정의하자면

1. 편리한 사용.
2. 빠른 속도.
3. 좋은 설계.

이 3가지를 뽑습니다. (물론, 에러가 없어야 하고 안정적이어야 하며 데이터는 항상 적합한 데이터가 나와야 합니다. 정말 너무나 당연한 이런 얘기들은 여기서는 다루지 않겠습니다. )

이 세 가지 중 개발자의 영역은 "빠른 속도"와 "좋은 설계"의 영역입니다.
개발자 취향마다 다를 수는 있겠지만, 그 둘 사이의 비중을 3:7 정도로 봅니다.

좋은 설계는 유지 보수성에 대한 얘기이고, 빠른 속도는 알고리즘과 락에 대한 얘기가 주가 될 것입니다.

경우에 따라서 두 가지가 충돌하는 수도 있는데, 일반적으로 저는 유지 보수성을 지키는 방향으로 결정합니다. 속도를 향상시킨다는 것은 결국 코드를 수정한다는 뜻인데 유지 보수성이 현격하게 떨어지는 코드를 수정한다는 것은 정말 미칠 일입니다.

그 둘 사이의 대표적인 충돌이 Builder pattern입니다. 일반적으로 Builder pattern은 비스무레한 객체 하나를 더 만들어내는 것 밖에 안 됩니다. 그냥 bean 객체 같은 거 잘 만들어 놓고 잘 사용하는 것보다 결코 빠를 수 없습니다. 게다가 gc가 버려야 할 객체를 하나 더 만들게 되죠. 하지만 유지보수 측면에서의 장점 때문에 쓰게 됩니다.

시작하기 전에 몇 가지만 말씀드리고 다음 글부터 본격적으로^^

OOP에 대한 기초가 부족한 분은 OOP에 대해서 먼저 제대로 공부하시기 바랍니다. OOP에 대한 부분까지는 본 글에서 설명하지 않습니다. OOP는 결코 초보자에게 쉬운 부분이 아닙니다. 제 경험상 OOP를 이해하고 있다는 사람 중 80%는 이해하지 못하고 있습니다. OOP나 자바의 기초를 결코 간과하지 마십시오.


각종 디자인 패턴에 대한 얘기들을 많이 할 겁니다. 대부분의 디자인 패턴은 성능보다는 좋은 설계를 위한 것입니다.
아쉽게도 프로그램의 세계에서는 만병통치약은 없습니다. 이런 저런 케이스에서 어떤 패턴을 어떻게 쓰는지에 대해서 설명하려 합니다.