as.wind.914

Java 메모리 영역 구조
- JVM은 힙을 아래와 같이 3개의 영역으로 나누고 있다.
   1) Permanent Space : JVM 클래스와 메소드 개체를 위해 쓰인다.
   2) Old Object Space : New 영역에서 count를 세어서 어느정도 증가된(만들어진지 좀 된) 개체를 위해 쓰인다.
   3) New(Young) Object Space : 새로 생성된 개체들을 위해 쓰인다.

New Object Space는 다시 3개의 부분으로 나누어 지는데, 모든 새로 생성된 개체들이 가는 Eden(에덴동산)과 그 개체들이 Old Generation으로 가지 전 생존해 있는 Survivor Space(From, To) 1과 2가 있다.

Java 메모리에 의한 Out of Memory 해결방법
JDK1.4에서부터 -XX:PrintGCDetails -XX:PrintGCTimeStamps -XX:PrintHeapAtGC 옵션을 사용하여 GC한 상태의 Heap 메모리 정보를 출력한다.
이 정보를 통해 New, Old, Perm의 영역 중에서 실제 어느 영역부분이 부족하여 Error가 발생하는지 찾은 후 부족한 영역의 Size를 조정해 주는방법으로 해결할 수 있다.
그러나, 부족한 영역에 계속해서 메모리 할당을 해주어도 사용률 100%가 나온다면 프로그램 누수일 수 있으니 프로그램을 점검해봐야 한다.
Heap 메모리 영역이 어느정도 차게되면 JVM은 계속해서 GC(Garbage Collection)를 시도하게 되는데, 이는 GC의 수행시간을 짧게하여 시스템 속도가 저하되는 상황이 나타날 수 있으며, 결국엔 Out of Memory가 발생하게 된다.

명령행 스위치	설명
-Xms=[n]	최소 Heap Size
-Xmx=[n]	최대 Heap Size
-XX:PermSize=[n]	최소 Perm Size
-XX:MaxPermSize=[n]	최대 Perm Size
-XX:NewSize=[n]	최소 New Size
-XX:MaxNewSize=[n]	최대 New Size
-XX:SurvivorRatio=[n]	New/survivor 영역 비율
-XX:newratio=[n]	Old/New 영역 비율. HotSpot 클라이언트 VM은 8, HotSpot 서버 VM은 2
-XX:TargetSurvivorRatio=[n]	GC동안 비율 생존자 수용 가능량 퍼센티지 (capacity percentage) 초기값은 50%

Struts2는 자바기반의 Web Application을 개발하는데 사용되는 Framework 이다. 자바 개발자라면 거의 모든이가 알고 있는 Apache Struts의 업그레이드 된 Framework 이다.

많은 자바 개발자들이 알고있듯이 Apache Struts는 자바 Web Application Framework의 대표로 자리 매김을 하였고, 다른 개발 Framework의 사용을 확산시키는데도 아주 큰 기여를 했다. 그러나 시간이 지나면서 개발자들은 웹 환경에 익숙한 사용자들의 다양하고 복잡한 요구사항을 접하게 되었고, Apache Struts가 그에 맞게 업그레이드를 거듭했지만 따라가기는 힘이 들었다. 또, 뒤이어 WebWork, Spring 등 많은 쉽고 간결하며 풍부한 사용자 인터페이서를 구축할 수 있는 Web Application Framework들이 등장하고, 개발자들은 Struts를 벗어나 다양한 Framework을 도입하여 개발하게 된다. (저 또한 Struts를 사용하다 어느정도 한계를 느껴 WebWork2을 Framework으로 사용을 하고 있었다.)
이에 Apache Struts는 Struts와 WebWork2를 결합하는 것으로 Struts2를 내놓게 되었다.

Struts2는 WebWork2와 결합하면서 MVC(Model View Controller)패턴을 구현한 내부 아키텍쳐가 WebWork2의 아키텍쳐로 완전히 달라졌다. Struts는 Servlet과 요청프로세스 기반으로 액션을 처리하는 구조대신 Filter와 인터셉터 기반의 WebWork2 아키텍쳐를 적용해 매우 유연하게 구축되었다. 나 또한 Struts에서 WebWork2로 갈아탄 이유가 Framework이 매우 유연하며, 설정이 작았기 때문이였다. 이 밖에도 Struts2는 아직도 다른 뛰어난 오픈 소스의 좋은 기능들을 쉽게 접목할여 활용할 수 있는 방향으로 계속해서 업그레이드가 되고 있다.

-- Struts2의 새롭게 달라진 모습
WebWork2 MVC 아키텍쳐 도입 : Struts와는 전혀 다른 WebWork2의 아키텍쳐를 적용 함.
인터셉터(Interceptor) : 인터셉터는 HTTP Request를 중간에 가로채서 처리된다는 것은 Filter와 비슷한 개념이나 액션의 실행 전과 후에 처리 할 코드를 다르게 구성할 수 있다. 인터셉터는 AOP 개념으로 Struts2 자체 내에 많은 인터셉터가 구현이 되어 있으며, 개발자가 필요에 따라 새로운 인터셉터를 등록하여 사용할 수도 있다. 복수의 인터셉트를 순서에 따라 실행도 가능하다.
간단한 설정과 빠른 리로딩 : Struts2에서는 환경 설정 또한 WebWork2를 거의 그대로 적용하여 기본값으로 사용하여도 많은 설정을 생략할 수 있게 되어 있다. 그리고, 설정도 extends와 include가 가능해 더욱 편리해졌으며, 변경 된 설정은 웹 컨테이너를 재시작하지 않고 빠르게 리로딩된다.
Framework에 종속적이지 않은 액션 : Struts1과는 다르게 Struts2의 액션은 Struts2 Framework에 종속되지 않게 디자인하여 프레임워크를 사용하면서도 프레임워크에 종속적이지 않으며, 쉽게 테스트가 가능하다.
의존성주입(Dependency Injection)의 지원 : 객체 간의 의존성 결합도를 낮추기 위해 구글 Guice Framework를 내부적으로 사용하고 있으며, Spring과 같은 뛰어난 Framework를 함께 사용할 수 있다.
Plugin 기능 : Struts2는 유용한 많은 오픈 소스 프레임워크를 쉽게 사용할 수 있도록 Plugin을 제공한다.
(JFreeChart, JasperReport, Sitemesh .. 등)
다양한 Result 타입 : Struts2는 가장 많이 사용하는 JSP외에도 많은 뷰 기술(Freemark, Velocity 등)을 지원하는 Result 타입을 사용할 수 있으며, 개발자 스스로 만들어 사용도 가능하다.
강력하고 많은 커스텀태그 지원 : 재사용성이 높은 많은 사용자 인터페이스 태그(커스텀태그)를 제공하며, 테마와 템플릿도 사용이 가능하다.

위에서 보는 것과 같이 Struts2에 새롭게 달라진 모습들이 많다. 그러나 여기서 가장 크게 달라지고 중요한 부분은 MVC 아키텍쳐가 변경되었다는 것이다. 그럼 Struts2에서 도입 된 WebWork2 MVC 아키텍쳐는 어떠한지 간략한지, Struts의 MVC 아키텍쳐와 어떻게 다른지를 알아보자. 다음에 Struts2 아키텍쳐 부분에서 자세히 다룰것이니 간단히 이해하고 넘어가도 무방할듯 하다.

-- Struts MVC 아키텍쳐 vs WebWork2 MVC 아키텍쳐
여기서 MVC 모델이 무엇이며, 왜 필요한지와 같은 문제는 다루지 않겠다. 궁금한이는 따로 알아보길 바란다. 여기서 이야기하는 Struts는 Struts2가 아닌 Struts1을 의미합니다.

먼저 Struts MVC와 WebWork2 MVC의 공통점은 초기 MVC 모델에서 업그레이드 된 Front Controller 방식을 이용한 MVC 모델이라는 것이다.

[ Front Controller MVC 패턴 ]

위 그림과 같이 Dispatcher가 Controller를 핸들링하는 구조입니다. Struts와 WebWork2에 모두 Dispatcher가 있습니다. 초기 대부분의 Web Application은 Page Controller 방식으로 개발이 되었습니다. Page Controller 방식은 요청이 많을 경우 부하가 걸린다는 것이고 하나의 페이지마다 하나씩의 Page Controllger가 만들어져야 한다는 문제점을 가지고 있었습니다. 그래서 이 문제점을 해결한 방식이 바로 Front Controller 방식 입니다. Front Controller 방식에서는 Controller는 핸들러와 복수개의 커맨드로 구현하여 이 문제점을 해결하였습니다.

Struts MVC와 WebWork2 MVC의 차이점은 Push Model & Pull Model 방식으로 나누어 집니다. Struts는 Push Model이고, WebWork2는 Pull Model 입니다.
그 차이점은 그림으로 보면 명확하게 알 수 있습니다.

[ Push Model ]

[ Pull Model ]

먼저 Struts가 해당하는 Push Model은 초기 MVC Model에 주로 채택되었던 방법으로 사용자의 요청에 의해 처리 된 결과를 View에 밀어넣는(Push) 방식이고, WebWork2가 속하는 Pull Model은 View에서 다수의 Controller로 부터 필요에 따라 처리 결과를 땡겨(Pull)오는 방식이다. Pull Model은 필요한 컴포넌트를 호출하여 처리하는 방식이 가능하기 때문에 이를 Component MVC라고도 부르며, 최근에 발표되는 많은 Web Application Framework이 이 방식을 사용한다.

Push Model : Struts, Spring ...
Pull Model : Struts2(WebWork2), Tapestry, JBossSeam, ...

이상 Struts2가 대체 무엇인가에 대해 간략하게 알아보왔다. 위 내용을 보고는 Struts2는 Java Web Application Framework 이며, 대략적으로 이러한 특징이 있구나 하는 것 정보만 이해하면 될 것이다. 이후 Struts2의 세부아키텍쳐 및 그 내용과 부가적인 부분들에 대해 알아본다.