|
Core Java Technologies Tech Tips에 오신 여러분을 환영합니다. Java
2 Platform, Standard Edition (J2SE)에 기반한 core Java technologies
와 APIs의 사용에 관한 최신 정보를 얻어 가시기 바랍니다. 이 글에서는 Java 2 Platform
Standard Edition Development Kit 5.0(JDK 5.0)을 사용합니다.
Download
JDK 5.0
이번 호에서는,
 제네릭(GENERIC)
JMX, JCONSOLE과 사용법
를 다루게 됩니다.
저자 John Zukowski
제네릭(GENERIC)
J2SE 5.0 버전은 Java 플랫폼에 대해 중요 언어 수준의 변경을 다소 포함하고 있다. 또한
J2SE 5.0은 루프와 매개변수의 강화와 같은 새로운 작업을 추가하여 JSR-14:
Add Generic Types To The Java Programming Language와
일치하는 제네릭(generic)을 통해 Java Collections 프레임워크와의 컴파일 타임
타입 안정성을 제공한다.
제네릭의 기본적인 사용법
중 하나는 컬렉션(collection)과 함께 사용할 때 데이터를 추상화하는 것이다. JDK 5.0
이전 버전에서는 Collection 생성시, 컬렉션 내부에 임의의 값을 줄 수 있었다. 예를 들면, 다음과 같다.
List myList = new ArrayList(10);
myList.add(new Integer(10));
myList.add("Hello, World");
사용자의 Collection을 특정 타입으로 제한하는 것은 어려운 일이며, 컬렉션으로부터 하나의 아이템을 뽑아내기 위해서는 캐스팅 연산이 필요하다.
Integer myInt = (Integer)myList.iterator().next();
만약 잘못된 타입으로 캐스팅을 한 경우에는 컴파일만 성공하고, 런타임시 예외가 발생하게 된다. 특별히 Collection
내의 모든 아이템을 Object로 처리하지 않는다면, 캐스팅은 보통 묵시적으로
발생하거나 캐스팅된 연산을 호출하기 전에 instanceof를 수행하여 발생한다.
Iterator listItor = myList.iterator();
Object myObject = listItor.next();
Integer myInt = null;
if (myObject instanceof Integer) {
myInt = (Integer)myObject;
}
이러한 상황은 제네릭의 미학적 가치를 떨어뜨린다. 제네릭을 이용하면 하나의 Collection에서 저장하고자 하는 오브젝트의 타입을 컴파일시 지정할 수 있다. 이렇게 되면 리스트에서 아이템을 추가하거나 검색할 때, 그 리스트가 특정 타입의 오브젝트가 활성화 될 것인지를 이미 알 수 있다. 따라서 캐스팅을 할 필요가 없는 것이다. "<>" 문자는 어떤 타입이 저장될 것인지를 지정하는데 사용합니다. 만약 잘못된 타입의 데이터가 주어진다면, 컴파일시 예외가 발생한다. 예를 들어, 다음 클래스를 컴파일하려 하면,
import java.util.*;
public class First {
public static void main(String args[]) {
List<Integer> myList = new ArrayList<Integer>(10);
myList.add(10);
myList.add("Hello, World");
}
}
다음의 에러가 발생한다.
First.java:7: cannot find symbol
symbol : method add(java.lang.String)
location: interface java.util.List<java.lang.Integer>
myList.add("Hello, World");
^
1 error
즉, 이 메시지는 기본적으로 해당 인터페이스가 Integer 오브젝트의 List에 대한
것일 때 add(String) 메소드는 사용할 수 없다는 것을 의미한다.
myList.add(10); 메소드는 리스트에 Integer
오브젝트 10을 add 하는 작업을 수행하였고, Autoboxing은 int
타입을 Integer로 변환하였다. 여기서 실패한 것은 String을 Integer의
List에 추가하는 것 뿐이다.
하나의 컬렉션의 엘리먼트로 작업을 하면서 그 컬렉션 내의 엘리먼트의 타입을 명시적으로 선언하지 않은 경우에도 경고를 받는다. 예를 들어, 다음 프로그램은 List를 생성하지만, 그 List 내에 어떤 타입이 저장될 지에 대해서는 지정하지 않는다.
import java.util.*;
public class Second {
public static void main(String args[]) {
List list = new ArrayList();
list.add(10);
}
}
이 프로그램을 컴파일 하면, 다음과 같은 경고를 받게 된다.
Note: Second.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
그 후 지시에 따라 -Xlint:unchecked를 javac 명령문에 추가하면
javac -Xlint:unchecked Second.java
다음과 같은 추가 정보가 표시된다.
Second.java:6: warning: [unchecked] unchecked call to add(E)
as a member of the raw type java.util.List
list.add(10);
^
이 메시지는 "add(E)" ” 호출에서 "E" 라는 List에 추가된 엘리먼트의 타입이 지정되지 않았다는 뜻이다. 그러나 이 메시지는 경고일 뿐, a.class 파일은 생성된다.
경고를 제거하고 싶으면 다음과 같이 <Object>를 List 선언시 추가하면 된다.
List<Object> list = new ArrayList<Object>();
여기서, Object는 E이고, 기본적으로 그 List에는 어떤 타입도 저장 가능하다는 것을 의미한다.
그런데 E는 어디서 온 것일까? java.util.List에서 인터페이스 선언부를 보면, 다음의 내용을 볼 수 있다.
public interface List<E> extends Collection<E>
이것은 문법적으로 E의 List를 하나 선언한 것이다.
나중에 인터페이스 선언시, 매개변수나 리턴 타입이 E로 교체된 메소드를 볼 수 있을 것이다.
Iterator<E" iterator();
ListIterator<E" listIterator();
boolean add(E o);
boolean addAll(Collection<? extends E" c);
E는 컴파일시 지정되기 때문에 타입 불일치를 찾기 위해 런타임 예외에 의존할 필요가 없다. addAll 라인의 ?는 알려지지 않은(unknown) 컬렉션으로 생각될 수 있지만, unknown은 E일 수도 있고, 서브클래스일 수도 있다. 이러한 구성으로 인해 정확한 타입 매칭만을 사용하지 않고도, 서브클래스들의 컬렉션으로 작업할 수 있다.
첫 번째 예제를 통해서 완벽하게 알 수는 없겠지만, 제네릭은 일반적으로 이터레이터(iterator)를 이용해 루프 강화(enhanced for loop )와 함께 사용된다. 제네릭이 없을 경우, String 오브젝트의 하나의 List를 루핑하려면 각각의 엘리먼트를 List로부터 적절한 타입으로 변환해야 한다. 그러나 제네릭과 루프 강화를 이용하면 모든 것이 간단해진다
다음은 제너릭과 루프 강화 없이 String 오브젝트들의 List를 루핑하는 기존 방법이다.
import java.util.*;
public class Old {
public static void main(String args[]) {
List list = Arrays.asList(args);
Iterator itor = list.iterator();
while (itor.hasNext()) {
String element = (String)itor.next();
System.out.println(element + " / " + element.length());
}
}
}
위의 Old 클래스를 컴파일/실행하고 다음과 같이 하나의 문자열을 매개로 실행하면,
java Old Hello
다음 결과를 얻게 된다.
Hello / 5
JDK 5.0을 이용하면 최신의 루프 구조 강화와 제네릭을 결합하여 컴파일시 타입 안정성이 보장되는 프로그램을 생성할 수 있으며, 가독성과 관리 용이성이 더 향상된다. 다음은 제네릭과 루프 강화를 사용할 경우 String오브젝트들의 List 전체 루핑이 어떻게 되는지 보여주는 예제이다.
import java.util.*;
public class New {
public static void main(String args[]) {
List<String> list = Arrays.asList(args);
for (String element : list) {
System.out.println(element + " / " + element.length());
}
}
}
java New Hello
Hello / 5
이와 같이, 제네릭과 루프 강화는 서로 잘 동작한다.
제네릭에 대한 좀 더 상세한 정보는 다음을 참조 하기 바란다.
JMX, JCONSOLE과 사용법
JSR-160은
JMX(Java Management Extensions) 1.2 버전 API를 확장하는 API를
정의하여 JMX MBean 서버에 원격 액세스를 제공한다. 2003년 1월 22일자 테크팁 Getting
Started with the Java Management Extensions(영문)를 다시
살펴보면, JMX API를 이용해 모니터링 및 관리를 할 수 있는 컴포넌트를 어렵사리 정의할 수
있다. 이러한 모니터링 및 관리 기능은 이제 J2SE 5.0의 표준이 되었으며, JSR-60에 의해
원격 핸들링이 향상되었다. JMX 입문에 관한 추가 정보는 J2EE의 테크팁 JMX
이해하기를 참조하기 바란다.
이번 테크팁에서는 이 전 Getting
Started with JMX 테크팁의 예제 코드를 이용하여 J2SE 5.0용으로 업데이트해
보자. 또한 실행중인 프로그램에 대해 통계를 디스플레이 하기 위한 최신 jconsole
툴의 사용법에 대해서도 공부해 보도록 하겠다.
"Getting Started with JMX" 테크팁에서는,
JAR 파일에 대한 클래스 경로를 명시적으로 추가해야만 예제 프로그램을 컴파일 및 실행할 수 있었다.
그러나 J2SE 5.0에서는 더 이상 JAR 파일을 클래스 경로에 명시적으로 추가할 필요가 없다.
J2SE 5.0에서는 JMX가 표준이 되었기 때문이다. 원본 소스를 약간 변경하는 것으로 프로그램은
표준 자바 개발 플랫폼에서 컴파일/실행될 것이다.
이전 테크팁에서 MBean 클래스(HelloMBean)에는 패키지가 없었다. 그러나 사용자가 만든 컴포넌트를 패키지에 포함시키는 것은 언제나 가장 좋은 방법이며, 이를 위해서는 사용자의 소스에 디렉토리를 만들어서 그 디렉토리 구조에 대해 패키지에 서술을 추가해 주면 된다.
package bean;
public interface HelloMBean {
public String getMessage();
public void setMessage(String message);
public int getChangeCount();
public void resetCounter();
}
이와 비슷하게, MBean 구현(Hello)에서 변경된 부분은 패키지 서술을 추가하는 것 뿐이다.
package bean;
public class Hello implements HelloMBean {
private String message;
private int changeCount;
public String getMessage() {
return message;
}
public void setMessage(String message){
this.message = message;
changeCount++;
}
public int getChangeCount() {
return changeCount;
}
public void resetCounter() {
changeCount = 0;
}
}
더 중요한 수정 사항은 컴포넌트를 생성하고 MBean 서버에 등록하는 에이전트(HelloAgent)이다. 여기에도
패키지 기술을 해 주어야 하며, MBeanServer를 구하는 방법을 약간
바꾸어 주어야 한다. J2SE 5.0에는 플랫폼 MBean 뿐 아니라 애플리케이션 MBean 까지도
사용할 수 있도록 설계된 MBeanServer이 도입되었으며, 연쇄 생성의
한 기점의 역할을 수행할 수 있다. 애플리케이션은 자신의 서버보다는 플랫폼 MBeanServer를
사용하기도록 권장된다. MBeanServer를 얻기 위한 이전의 방법은 javax.management
패키지를 임포트하고 MBeanServerFactory의 createMBeanServer
메소드를 호출하여 서버를 생성해야했다.
MBeanServer server =
MBeanServerFactory.createMBeanServer();
새로운 방법은 기본적으로는 이전과 동일하지만, 관리 자원을 다중 에이전트 대신 단일 에이전트(플랫폼 MBeanServer)에
등록할 수 있다. 플랫폼 MBeanServer를 얻기 위해서는 ManagementFactory.getPlatformMBeanServer를
호출해야 하며, ManagementFactory 클래스는 java.lang.management 패키지에
있다.
MBeanServer server =
ManagementFactory.getPlatformMBeanServer();
다음은 HelloAgent의 업데이트 버전이다.
package bean;
import java.lang.management.*;
import javax.management.*;
public class HelloAgent {
public static void main(String args[]) {
MBeanServer server =
ManagementFactory.getPlatformMBeanServer();
HelloMBean hello1 = new Hello();
HelloMBean hello2 = new Hello();
try {
ObjectName helloObjectName1 = new ObjectName(
"bean:type=Hello,name=hello1");
server.registerMBean(hello1, helloObjectName1);
ObjectName helloObjectName2 = new ObjectName(
"bean:type=Hello,name=hello2");
server.registerMBean(hello2, helloObjectName2);
System.out.println("Waiting...");
Thread.sleep(Long.MAX_VALUE);
} catch (InterruptedException e) {
System.out.println("Sleep stopped");
e.printStackTrace();
} catch (MalformedObjectNameException e) {
System.out.println("Bad object name");
e.printStackTrace();
} catch (InstanceAlreadyExistsException e) {
System.out.println("Already exists");
e.printStackTrace();
} catch (MBeanRegistrationException e) {
System.out.println("Registration problems");
e.printStackTrace();
} catch (NotCompliantMBeanException e) {
System.out.println("Registration problems");
e.printStackTrace();
}
}
}
이제, jconsole 툴을 살펴보자. JDK 5.0에는 실행중인 자바에 첨부된 jconsole이라고 하는 최신 Swing 기반의 툴이 포함되어 있으며, MBean 속성 및 동작 뿐 아니라 프로그램의 성능, 메모리 사용량, 스레드 스택 추적에 대한 통계를 보여준다. 또 하나 주목할 것은 jconsole을 이용하면 HtmlAdaptorServer를 생성할 필요가 없다는 것이다.
jconsole과 업데이트된 예제 프로그램을 같이 사용하기 위해서는 3가지 클래스(HelloMBean, Hello, HelloAgent)를 컴파일하고 적절한 명령문을 이용하여 이를 실행해야 한다. 이 3개의 클래스를 컴파일할 때, 이 클래스들은 단일 패키지 안에 있다는 점을 기억하기 바란다.
이 클래스들을 컴파일 할 때 Windows 환경에서는 아래의 명령문을 사용하면 된다. 이 명령문을 생성된 클래스 위치의 상위 디렉토리에서 실행하고, "bean" 대신 파일을 생성한 위치의 실제 이름으로 교체하자.
javac bean\*.java
이 명령문은 소스 파일이 있는 디렉토리에 .class 파일을 생성합니다. 다른 디렉터리에 생성하고자 한다면, -d 옵션을 사용하기 바란다.(단, 새로운 위치가 클래스 경로로 잡혀 있는지 확인해야 한다).
Solaris 운영체제나 Linux나 Mac 환경에서는 슬래시 방향만 바꿔주면 된다.
javac bean/*.java
모니터링 기능이 가능하도록 JMX 활성 프로그램을 실행하려면 다음과 같이 com.sun.management.jmxremote 명령문 속성을 설정해야 한다.
java -Dcom.sun.management.jmxremote HelloAgent
main() 메소드 끝에서 Thread.sleep()을
호출하므로 이 메소드는 즉시 리턴하지 않을 것이며, 이 시점에서 JMX 에이전트가 실행되는 동일 호스트에서
jconsole을 시작해야 한다. 이를 시작하기에 앞서 HelloAgent
프로그램이 실행되고 있는지 확인하기 바란다. jconsole을 시작하는 데에는 2개의 옵션을 사용할
수 있다. 즉, 새로운 jps 명령문 툴을 가진 에이전트 프로그램의 프로세스 아이디(PID)를 찾아서
명령문 옵션에 주거나, 아무런 옵션 없이 시작하여 프로그램에서 찾을 수도 있다. PID를 지정하지 않고
jconsole을 시작하려면 다음 명령문을 실행하기 바란다.
jconsole
PID 없이 시작하면 초기에 "JConsole:
Connect to Agent" 창이 표시된다. 한편, HelloAgent가 실행 중이면 리스트에서
PID를 찾을 수 있다.
해당 에이전트를 선택하고 Connect 버튼을 누른다. 그러면 초기 Summary 화면이 나타난다.
Memory, Threads, Classes 탭은 초기 화면의 요약 정보를 포함하고 있으며, 이 탭들을 선택하면 추가 정보를 볼 수 있다.
Memory 탭은 힙 메모리 사용량과 각 메모리 풀의 사용량을 차트로 보여준다. 가비지(garbage)
컬렉션 콜을 요청하면 가비지 컬렉션 런타임도 볼 수도 있다.
Threads 탭은 실행중인 스레드의 수를 표시한다. 리스트에서 특정한 스레드를 선택하면 해당
스택을 추적할 수 있다.
Classes 탭은 한 번에 몇 개의 클래스가 로딩되어 있는지를 볼 수 있다. Verbose Output 체크박스를 체크하면 클래스가
추가로 로딩될 때마다 콘솔에 표시되며, 이 클래스는 시스템이 생성한 클래스일 경우가 있으므로 반드시
인식해야 할 필요는 없다.
MBeans 탭은 기본적으로 이전의 브라우저 기반 에이전트 뷰를 대신한 것이다. 여기서는 bean을
찾아서 그 속성을 수정하고 실행할 수 있다.
VM 이름의 레이블이 붙은 마지막 탭은 가상 머신이다. 운영체제 정보와 런타임 플랫폼에 대한
상세정보를 보여준다.
한 가지 알아두어야 할 것은 jconsole을 이용하기 위해서 반드시 MBean을 사용할 필요는 없다는 점이며,
jconsole을 시작하기 전에 -Dcom.sun.management.jmxremote
옵션으로 프로그램을 시작했는지에 대해서만 확인하면 된다.
JMX에 관한 좀 더 많은 내용은 다음 문서들을 참조하기 바란다.
|
