(이클립스 버그가 은근히 있어요~ 다른 버전은 모르겠지만, Juno 버전은 많은 사람들이 공통적으로 겪는 꽤 많은 버그가 있는 것으로 알고 있습니다.)
가끔 이미 삭제되어 존재하지도 않은 파일에 Breakpoint 가 걸려있어, 매 번 디버깅할 때마다 무언가 걸려서 'Soure not found' 메시지를 띄워주기도 하고. 또 분명 Breakpoint 를 해제했음에도 불구하고, 계속해서 Breakpoint가 잡히는 경우도 있습니다.
그럼 모든 Breakpoint 를 해제하고(당연히 삭제되어 있는 파일에 존재하는 Breakpoint도 말이지요~), 새롭게 설정하면 좋겠는데요.
도대체 Breakpoint는 어디서 볼 수 있는 것일까요? 설정한 파일마다 모두 직접 찾아봐야 하는 것일까요? 아니면 Breakpoint 를 모두 모아놓은 메뉴가 있는 걸까요?
물론 프로젝트에 현재 설정되어 있는 모든 Breakpoint를 한 눈에 확인할 수 있는 기능을 Eclipse는 제공하고 있습니다.
이클립스의 우측 상단에 보시면 [ JAVA | Debug ] 등 다양한 Perspective 가 표시됩니다. 여기서 Debug Perspective 를 선택합니다. (SVN을 사용하신다면 SVN에 대한 Perspective 도 여기에 표시됩니다.)
만약 Debug Perspective 아이콘과 텍스트가 보이지 않는다면 Open Perspective 아이콘을 클릭하여 Debug Perspective 를 열어주면 됩니다.
Debug Perspecitve 가 빨간 박스에 표시되고 있습니다.
(Debug 바로 우측으로 두번째에 위치한, '네모상자와 작은 더하기' 아이콘 메뉴가 Open Perspective입니다.)
Debug Perspective 모드가 선택되면 디버그와 관련된 다양한 탭이 바로 하단에 뜨는데요, 여기서 Breakpoints 탭을 선택합니다.
해당 탭에는 프로젝트에 설정되어 있는 모든 Breakpoint들을 한 눈에 확인하실 수 있습니다.
만약 Breakpoint 지정은 유지시키되, 실제 기능만을 비활성화 시키려면 특정 Breakpoint의 좌측 체크박스를 체크 해제만 하면 됩니다.
반대로 다시 활성화 시키시려면 체크를 하면 되구요.^^ 간단하지요.
하지만 우리가 원하는 것은 모든 Breakpoint의 해제(삭제)입니다.
Breakpoints 탭의 빈 영역에 마우스 커서를 두고 우측 버튼을 클릭합니다. 컨텍스트 메뉴가 뜨면 메뉴에서 'Remove All'을 선택합니다.
이 기능이 바로 해당 프로젝트에 설정되어 있는 모든 Breakpoints 를 제거하는 일을 합니다. (간단합니다.^^)
정말 삭제할 것인지 다시 한번 묻습니다. 'Yes'를 클릭합니다.
일단 한번 제거된 Breakpoint 들은 다시 복구할 수 없습니다. 그러니 중요 디버깅 작업 중이시라면 관련 Breakpoint들도 모두 삭제되니, 신중히 체크 해제하시기 바랍니다.^^
모든 Breakpoints 들이 사라진것을 확인하실 수 있습니다.
이렇게 Breakpoint 들을 제거하시면 이클립스 버그로 인해 제대로 해제되지 않던 것들. 그리고 실제 파일이 삭제되었음에도 불구하고 삭제된 파일의 Breakpoint 가 존재한다고 인식하여 File not Found 오류 메시지를 보여주던 것들이 모두 해결 됩니다.^^
꽤 많은 분들이 디버거의 존재 자체를 모르고 있거나 혹은 디버거가 있다는 사실은 알아도 그 효용성에 의문을 제기하곤 합니다. 왜냐하면, 우리에겐 Log 클래스나 혹은 printf같은 훌륭한(?) 디버깅 도구가 있다고 생각하기 때문이죠. 물론 이렇게 필요한 변수를 찍어보면서 어떤 곳에서 버그가 있는지를 알아보는 일이 잘못된 일은 아닙니다만 복잡한 여러 상황이 맞물려 재현되는 버그는 이러한 고전적인(?) 방법을 써서 알아보기가 매우 어렵습니다.
원인을 정확히 그리고 빨리 파악하려면 디버거의 사용법을 숙지하고 사용하는 것이 가장 좋습니다. 대부분의 개발 환경에서 디버거를 제공하는데 다행히 이클립스에서도 쓸만한 디버거를 내장하고 있습니다.
오늘 포스팅에서는 이클립스 디버거 사용법에 대해 다루어 볼까 합니다.
이클립스 디버거 뷰
이클립스는 디버거 뷰를 제공하여 디버거를 사용할 수 있도록 합니다. 디버거 뷰는 어디에서 확인할 수 있을까요? 바로 우측 상단에 Debug 뷰에 들어가면 그곳에서 확인할 수 있습니다.
디버깅의 시작
그렇다면 어떻게 디버깅을 활성화한 상태로 프로그램을 실행할 수 있을까요? 상단 메뉴의 Run에서 프로그램을 실행할 때 Debug를 이용하여 프로그램을 실행하면 디버거가 작동하게 됩니다.
브레이크 포인트 설정과 뷰
보통 디버깅을 할 때 가장 먼저 하는 일이 브레이크 포인트를 잡는 일입니다. 브레이크 포인트를 에러가 일어나는 라인이나 혹은 의심이 가는 변수를 추적할 수 있는 라인쯤에 잡아놓고 프로그램을 디버깅하면 해당 라인을 실행할 때 디버거가 작동하게 되고 그곳에서 프로그램을 라인 별로 진행해가며 관찰을 진행할 수 있게 됩니다.
브레이크 포인트 설정은 매우 간단합니다. 편집기 왼쪽에 파란 부분(마커 바)을 더블 클릭하게 되면 파란 원이 생기는데 이 원이 브레이크 포인트입니다. 혹은 오른 클릭하여 Toggle break point를 누르면 됩니다. 설정 후 다시 더블 클릭하게 되면 브레이크 포인트가 사라지게 됩니다.
또한, 디버그의 브레이크 포인트 뷰에서 지금까지 걸어놓은 모든 브레이크 포인트들의 위치를 확인할 수 있고 활성화/비활성화, 삭제도 할 수 있습니다. 여러 브레이크 포인트가 걸려있을 때에는 이 탭에서 확인하고 관리하는 것이 더 편합니다.
또한, 디버깅을 진행하고 있는 도중에도 다른 의심이 가는 라인에 브레이크 포인트를 걸 수 있습니다.
스텝 단위 진행
지정한 브레이크 포인트에 다다르면 동시에 디버거가 작동하게 되고 그 라인부터 스텝 단위의 진행을 할 수 있게 됩니다.
이제 이 뷰의 버튼들을 이용하여 현재 상황을 진행하거나 되돌릴 수 있습니다. 자주 사용하는 버튼의 사용법을 알아보면
Resume : 다음 브레이크 포인트를 만날때까지 진행합니다.
Suspend : 현재 작동하고 있는 쓰레드를 멈춥니다.
Terminate : 프로그램을 종료합니다.
Step Into : 메서드가 존재할 경우 그 안으로 들어가 메서드 진행 상황을 볼 수 있도록 합니다.
Step Over : 다음 라인으로 이동합니다. 메서드가 있어도 그냥 무시하고 다음 라인으로 이동합니다.
Step Return : 현 메서드에서 바로 리턴합니다.
Drop to Frame : 메서드를 처음부터 다시 실행합니다.
등이 있습니다.
실제로 디버깅 화면에서 버튼들을 눌러보면 쉽게 그 쓰임새를 아실 수 있습니다.
변수의 상태 확인을 쉽게 해주는 변수 뷰
디버깅을 진행하는 도중 변수의 값이나 객체의 상태를 알고 싶은 상황이 생기게 됩니다. 현재 의심이 가는 변수 이외에도 이 변수에 영향을 끼칠 다른 변수들이나 객체들의 상황을 실시간으로 검사할 필요가 있을 때 변수 뷰를 이용하면 도움을 얻을 수 있습니다.
이곳에서 변수나 객체의 상태를 확인하고 변수의 상황에 대해서 저장할 수 있습니다. 변수나 객체의 상황을 모두 저장해서 클립보드에 붙이고 싶은 일이 생기면 해당 변수를 오른클릭 후 Copy Variables를 선택합니다.
편집 창으로 돌아가 변수에서 Command + shift + i를 누르게 되면(혹은 오른 클릭 후 Inspect를 선택) Inspector 창이 뜨게 됩니다. 이 창에서 다시 한번 Command + shift + i를 누르면 해당 변수를 Expression 뷰로 보내게 되고 이곳에서 지속해서 변수의 상태를 관찰할 수 있게 됩니다.
Expression 뷰 이용
Expression 뷰에서는 변수 이름을 입력하거나 수행해보고 싶은 명령어를 직접 입력하여 그 결과 값을 관찰할 수 있습니다. 결과 값을 관찰할 뿐만 아니라 Expression에 써놓은 변수들은 명시적으로 지우지 않는 이상 계속해서 관찰을 수행하기 때문에 변해가는 상황을 지속해서 관찰할 일이 있는 변수나 명령문을 등록해놓기에 좋습니다.
Display 뷰 이용
디스플레이 뷰에서는 현 문맥에서 사용할 수 있는 명령어를 실행하거나 변수의 값을 조작하는 일을 수행하기에 적합한 환경을 제공합니다. Expression에서도 비슷한 기능을 제공하지만, 디스플레이 뷰를 이용하는 것이 더 편합니다. 메모장과 같이 쉽게 쓰고 지울 수 있기 때문입니다.
또한, 원본 코드의 수정 없이 편하게 현재의 맥락을 변화시킬 수 있는 것이 가장 큰 장점이라고 볼 수 있습니다.
필요한 명령어들을 적어놓은 후 실행하고 싶은 부분만 드래그하여 수행하거나 혹은 값을 리턴받을 수 있습니다. 지금은 boolean변수 하나의 값을 바꿔보기도 하고 조건 값에 따라 무언가를 리턴 받도록도 해놓은 상황을 스크린 샷으로 담아보았습니다.
값을 반환받고 싶을 때는 두 번째 버튼을, 단순히 실행만 할 때에는 세 번째 버튼을 누르면 됩니다.
두 번째 버튼을 눌러 값을 반환받는 상황입니다.
단순히 실행만 하려면 세 번째 버튼을 누릅니다.
브레이크 포인트에 조건 걸기
브레이크 포인트에 조건을 거는 것이 굉장히 유용할 때가 있습니다. 특히 반복문안에 들어가 있는 코드들을 디버깅할 때 유용하지요. 반복문의 경우 모든 상황을 검사한다기보다는 특정 조건에서 값이 어떻게 들어가는지를 분석하는 경우가 더 많은데 이러한 상황을 검사하기 위해서 브레이크 포인트에 조건을 걸어야 합니다.
브레이크 포인트를 거는 과정까지는 똑같습니다. 브레이크 포인트를 건 후 그 포인트에서 오른 클릭을 하면 Breakpoint properties 옵션이 있는 것을 확인할 수 있습니다. 이 옵션에서 조건문을 설정하여 디버거의 활성화 조건을 설정할 수 있습니다.
먼저 Conditional을 활성화하여 어떤 조건에서 디버깅 화면으로 전환할지를 쓰면 되는데 이 창에 조건식을 쓰면 됩니다.
또 hit count를 이용하여 조건을 걸 수도 있습니다. hit count에 값을 적용하면 해당 라인에 브레이크 포인트가 hit count만큼 잡힌 이후 디버깅 화면으로 전환하게 됩니다. hit count옵션은 반복문에서 한 100번쯤 이후에 디버깅을 시작하고 싶거나 하는 일이 생길 때 유용하게 쓸 수 있습니다.
이클립스(Eclipse)를 처음 설치하게 되면 폰트가 너무 작거나 자신이 선호하는 폰트가 아닐 수 있습니다.
특히나 대부분의 이클립스 버전에서 처음 설치 후, 한글이 포함된 소스파일을 불러오면 한글이 매우 작게 표시됩니다.
아래는 소스코드에 한글 주석을 달아보았습니다. 유독 한글이 작습니다.
이클립스에서 기본 지정된 폰트가 한글에는 잘 안맞는 것 같습니다.
폰트를 변경해 보겠습니다.
이클립스 상단 메뉴에서 [Windows - Preferences]를 선택합니다.
Preferences 다이얼로그 창이 뜨면 좌측 트리메뉴에서 [General - Appearance - Colors and Fonts] 를 선택합니다.
우측 Colors and Fonts 에서 Basic - Text Font 를 선택합니다.
그러면 좌측 버튼들이 일부 활성화 되는데요.
여기에서 [Edit...] 버튼을 클릭합니다.
글꼴 설정 다이얼로그 창이 뜨면 폰트를 선택합니다.
여기서는 제가 선호하는 폰트인 Verdana 를 선택했습니다. 크기는 10으로 설정합니다. 이 크기로 설정하면 제가 원하는 한글 폰트 사이즈로 한글이 표시됩니다. 자신이 사용하기 원하는 폰트를 선택한 후, [확인] 버튼을 클릭합니다.
Preferences 다이얼로그 창으로 빠져나왔다면 [OK] 버튼을 클릭하여 폰트 변경 사항을 저장하고, 창을 닫습니다. Preferences 창을 닫지 않고, 적용사항을 바로 적용시키려면 [Apply] 버튼을 클릭하시면 됩니다.
다시 소스 파일로 돌아와보면!
짜잔 한글이 더 커졌습니다^^
제가 선호하는 폰트 및 글자 크기를 선택한 것이기 때문에 다른 폰트를 원하시거나 더 큰 사이즈를 원하신다면 글꼴 창에서 이를 변경하시면 됩니다. 지금까지 이클립스 한글 폰트가 작은 경우에 변경하는 방법에 대해 알아보았습니다. 한글 폰트 뿐만 아니라, 이클립스에서 사용되는 다양한 영역의 폰트를 설정할 수 있으니, 자신에게 맞는 폰트를 설정하실 수도 있습니다.
JUnit개발 가이드는 이클립스 + springMVC + maven 개발환경 기반으로 작성하였다.
2.1 JUnit 라이브러리 추가 JUnit을 사용하려면 프로젝트에 JUnit 라이브러리가 필요하다. Maven프로젝트는 의존관계 설정이 쉽게 되어 기존 프로젝트에서 처럼 개발자가 해당 라이브러리를 찾는 수고를 덜어준다. Project Object Model(POM.xml) 에서 아래 그림1과 같이 Dependencies탭에서 JUnit을 찾아 추가를 하면 된다.
그림1
또는 직접 POM.xml에 dependencies element에 JUnit dependency를 아래와 같이 직접 추가할 수도 있다.
위와 같이 추가를 하게 되면 Maven 프로젝트 Install시 해당 라이브러리가 그림2와 같이 로컬 저장소에 저장하게 된다.
그림2
그림3
2.2 프로젝트 패키지 구성
JUnit테스트를 하기 위해서는 테스트 대상 클래스와 테스트 클래스는 같은 패키지 내에 있어야 한다. Maven 프로젝트를 생성하게 되면 Maven 관례에 따라, 그림3과 같은 프로젝트 템플릿이 기본적으로 생성된다. 그림3의 ① 디렉토리 /src/main/java/는 자바 코드를 보관하고 단위 테스트의 소스는 ② 디렉토리/src/test/java/ 디렉토리에 보관한다. ③ 테스트 하고자 하는 클래스가 포함된 패키지명과 동일하게 테스트 클래스를 포함하는 패키지도 동일하게 구성한다. ④ 테스트 대상 클래스와 테스트 클래스의 생성 예이다.
3. JUnit 테스트 클래스 작성
3.1 간략한 계산기 클래스 테스트
그림3의 프로젝트 패키지 구성에서 /src/main/java/ 디렉토리에 Calurator.java 클래스를 아래와 같이 작성한다.
package com.y2kpooh.junitTest;
public class Calcurator { public double sum(double a, doubleb){ return a + b; } }
위 Calcurator클래스는 double형의 두개의 파라메터를 받아 두 파라메터의 합을 구하여 double형으로 리턴해주는 sum 메서드를 가지고 있다. 물론 위 클래스는 문제가 될리 없는 간단한 프로젝트이나 테스트 클래스 작성에 이해를 돕기 위함이다.
Calurator클래스 작성 후 해당 클래스를 테스트 하기 위한 테스트 클래스를 작성해보자. 그림3의 프로젝트 패키지 구성에서 /src/test/java/ 디렉토리에 CaluratorTest.java 클래스를 아래와 같이 작성한다.
public class CaluratorTest { ← ① @Test ← ② public void testSum(){ Calcurator c = new Calcurator(); double result = c.sum(10, 50); ← ③ assertEquals(60, result, 0); ← ④ } }
① 테스트 클래스는 반드시 public으로 선언해야 하며 클래스명은 관례에 따라 테스트클래명 + Test 끝나는 이름으로 사용된다. JUnit 3에서는 TestCase클래스를 상속받아 사용해야 했으나 JUnit 4에서는 상속받지 않아도 된다. (이 문서는 JUnit 4를 기반으로 작성되었다.) ② @Test 어노테이을 선언하여 testSum 메서드가 단위 테스트 메서드임을 선언하였다. 클래스명과 마찬가지로 테스트 메서드는 test + 테스트메서드명으로 선언한다. @Test 어노테이션을 선언한 메서드는 JUnit이 알아서 실행을 해준다. ③ Calcurator 클래스의 인스턴스를 선언하여 sum 메서드에 10, 50 인자값을 세팅하여 result변수에 결과값을 리턴 받는다. ④ JUnit 프레임워크에의 Assert 클래스의 정적 메서드인 assertEquals를 이용하여 테스트 결과 값을 확인한다. assertEquals(expected, actual, delta)는 assertEquals(예상값, 실제값, 허용오차)
CalcuratorTest 클래스 테스트 결과 그림4와 같이 테스트 성공 결과가 나온다.
그림4
3.2 JUnit assert 주요 메서드 및 사용예시
assert 메서드
설명
assertArrayEquals(a, b);
배열 A와 B가 일치함을 확인한다.
assertEquals(a, b);
객체 A와 B가 일치함을 확인한다.
assertSame(a, b);
객체 A와 B가 같은 객임을 확인한다. assertEquals 메서드는 두 객체의 값이 같은가를 검사는데 반해 assertSame메서드는 두 객체가 동일한가 즉 하나의 객인 가를 확인한다.(== 연산자)
Spring 기반의 테스트 코드 작성을 위해 테스트 클래스 상단에 @RunWith(SpringJUnit4ClassRunner.class) 구문을 추가한다. Spring 프레임워크 context 파일을 테스트 수행시에도 동일하게 로딩하기 위해 @ContextConfiguration(locations={"file:WebContent/WEB-INF/classes/applicationContext*.xml"}) 과 같은 형태로 프로젝트의 스프링 설정파일을 설정해 준다.
메서드 수행시간 제한하기
@Test(timeout=5000)
단위는 밀리초이며 이 메서드가 결과를 반환하는데 5,000밀리초가 넘긴다면 테스트는 실패한다.
Exception 테스트
@Test(expected=RuntimeException.class)
해당 클래스는 RuntimeException이 발생해야 한다. 만약 테스트에서 RuntimeException이 발생하지 않을 경우 실패한다.
테스트 건너뛰기
@Test(timeout=5000) @Ignore(value=”여기는 테스트 안할거야”)
@Ignore 어노테이션을 추가하면 해당 메서드는 테스트를 건너뛰게 되며 JUnit4는 성공 및 실패 개수와 함께 건너뛴 테스트 수도 포한된 결과 통계를 제공한다.
초기화 및 종료
@Before [...] @After [...]
@Before 어노테이션이 선언된 메서드는 해당 테스트 클래스의 인스턴스, 객체를 초기하 하는 작업을 한다. @After 어노테이션이 선언된 메서드는 해당 테스트 실행 후 실행된다. 해당 @Before, @After 어노테이션 이외 @BeforeClass, @AfterClass도 있으며 이는 static 메서드와 동일한 형태로 테스트 클래스 실행 시 한번만 실행된다.
4. 목 객체를 활용한 테스트
4.1 목(Mock) 객체란? 어플리케이션플리케이션을 개발하다보면, 테스트 대상 코드가 다른 클래스에 종속되어 있을 때가 종종 있다. 그 클래스가 다시 다른 클래스에 종속되고, 역시 또 다른 클래스에 종속되기도 한다. JDBC를 통해 데이터베이스에 의존하는 JAVA EE 애플리케이션, 파일 시스템을 사용하는 어플리케이션, HTTP나 SOAP 등의 프로토콜로 외부 리소스에 접근하는 어플리케이션들을 예로 들 수 있다. 특정 런타임 환경에 의존적인 어플리케이션을 단위 테스트하는 것은 꽤나 고된 일이다. 테스트는 안정적이어야 하고, 반복적으로 수행해도 매번 동일한 결과를 내야 한다. 따라서 테스트를 올바로 수행하기 위해서는 환경을 제어할 수 있어야 한다. 예를 들어 다른 회사에 제공하는 웹 서버에 HTTP 커넥션을 맺는 어플리케이션을 제작하는 경우 그 외부 서버를 개발 환경 안에 가져올 수 없다. 테스트를 작성하고 돌려 보려면, 결국 서버를 시뮬레이션하는 방법이 필요하다. 또는 팀 단위 프로젝트에서 내가 맡은 부분을 테스트해보려 할때 다른 부분이 아직 준비되지 않았다면... 가짜를 만들어 미처 준비되지 못한 부분을 시뮬레이션할 수 있다. 이 처럼 가짜 객체를 제공하는 테스트 방식으로 목 객체를 사용할 수 있다.(스텁방식도 있다.)
4.2 목 객체를 활용해 단위 테스트 하기 한 은행 계좌에서 다른 계좌로 송금하는 단순한 테스트 케이스이다. 위 계좌 송금 프로세스를 기능 테스트 하기 위해서는 AccountService를 테스트 하기 위해서는 우선 데이터베이스를 세팅한 후 테스트 데이터를 채워넣는 작업을 진해하여야 한다. 목 객체를 활용하면 아직 작성되지 않은 코드를 테스트할 수 있다. 단 인터페이스가 정의되어 있어야 한다.
Account.java 계좌 ID와 잔고를 갖는 Account 객체
package com.y2kpooh.mock;
public class Account { /** * 계좌 아이디 */ private String accountId;
public class TestAccountService { @Test public void testTransferOk() { //테스트를 하기위한 객체 생성 및 준비 MockAccountManager mockAccountManager = new MockAccountManager(); Account senderAccount = new Account( "1", 200 ); Account beneficiaryAccount = new Account( "2", 100 ); mockAccountManager.addAccount( "1", senderAccount ); mockAccountManager.addAccount( "2", beneficiaryAccount ); AccountService accountService = new AccountService(); accountService.setAccountManager( mockAccountManager ); // 테스트 수행 accountService.transfer( "1", "2", 50 ); // 결과 검증 assertEquals( 150, senderAccount.getBalance() ); assertEquals( 150, beneficiaryAccount.getBalance() ); } }
테스트 결과 및 프로젝트 패키지 구성화면
그림5
4.3 목 프레임워크 활용하기 목 객체를 활용하여 테스트 하려면 목 객체를 직접 개발자가 만들어야 한다. 바쁜 프로젝트 일정에 테스트하려고 목 객체를 만들자니 배보다 배꼽이 큰 것 같은 생각이 들지도 모른다. 역시나 천재들이 만들어 놓은 훌륭한 목 프레임워크가 존재 한다. EasyMock과 JMock이 있으며 해당 라이브러리만 세팅하면 쉽게 목 객체를 활용할 수 있다.
테스트를 하고자 하는 클래스 AccountService는 이미 완성되어 있으며 해당 클래스를 테스트 하기 위해서는 AccountManager에 대한 Implement Class가 없다. 이 AccountManager에 대한 클래스를 EasyMock을 이용해서 테스트 가능하다. (4.2 목 객체를 이용한 테스트 케이스에서는 AccountManager의 Implement Class로 MockAccountManager 클래스를 작성하여 테스트가 가능했었다. 여기서 꼭 기억할 것은 목 객체를 이용하여 테스트하기 위해서는 꼭 인터페이스가 정의되어 있어야 한다.)
- Xms로 init 메모리를 잡고, committed 도달할 때까지 Used용량이 점차 증가하는데,
committed에 도달시 메모리 추가할당시 시스템 부하발생 (WAS가 몇 ms가량 멈출 가능성 있음)
- 메모리 용량은 init < used < committed < max
- 보통 운영시스템에서 Xms와 Xmx를 동일하게 지정하는 이유는 init와 max사이에서 used 메모리가 committed까지 사용하게 되면,
신규 메모리 공간을 요구하는데 이 때 약 1초가량 jvm이 메모리 할당 중 멈춰버리는 경우가 있다.
그래서 Xms와 Xmx를 동일하게 주고 메모리를 확보한 상태에서 jvm을 기동시키곤 한다.
출처 : http://javaslave.tistory.com/23
JVM 이란?
Java Virtual Machine 의 줄임말 이며 Java Byte Code를 OS에 맞게 해석 해주는 역할을 합니다. Java compiler는 .java 파일을 .class 라는 Java byte code로 변환 시켜 줍니다. Byte Code 는 기계어가 아니기 때문에OS에서 바로 실행되지 않습니다. 이때 JVM은 OS가 ByteCode를 이해할 수 있도록 해석 해줍니다. 하지만 JVM의 해석을 거치기 때문에 c언어 같은 네이티브 언어에비해 속도가 느렸지만 JIT(Just In Time)컴파일러를 구현해 이점을 극복했습니다. Byte Code는 JVM 위에서 OS상관없이 실행된다. 이런 점이 Java의 가장 큰 장점이라고 할수 있습니다. OS에 종속적이지 않고 Java 파일 하나만 만들면 어느 디바이스든 JVM 위에서 실행 할 수 있습니다. JVM은 크게 Class Loader, Runtime Data Areas, Excution Engine 3가지로 구성되어 있고 자세한 설명은 아래에 이이서 하겠습니다.
JVM 구조
Class Loader
RunTime 시점에 클래스를 로딩하게 해주며 클래스의 인스턴스를 생성하면 클래스 로더를 통해 메모리에 로드하게 됩니다.
Runtime Data Areas
JVM이 프로그램을 수행하기 위해 OS로 부터 별도로 할당 받은 메모리 공간을 말하며, Runtime Data Areas는 크게 5가지 영역으로 나눌 수 있습니다.
Execution Engine
Load된 Class의 ByteCode를 실행하는 Runtime Module이 바로 Execution Engine입니다. Class Loader를 통해 JVM 내의 Runtime Data Areas 에 배치된 바이트 코드는 Executin Engine에 의해 실행되며, 실행 엔진은 자바 바이트 코드를 명령어 단위로 읽어서 실행합니다.
최초 JVM 이 나왔을 당시에는 Interperter방식(한 줄씩 해석하고 실행)이였기 때문에 속도가 느리다는 단점이 있었지만 JIT complier 방식을 통해 이 점을 보완했습니다. JIT는 ByteCode를 어셈블러 같은 NativeCode로 바꿔서 실행이 빠르지만 역시 변환하는데 비용이 발생합니다. 이 같은 이유 때문에 JVM은 모든 코드를 JIT Compiler 방식으로 실행하지 않고 Interpreter 방식을 사용하다 일정한 기준이 넘어가면 JIT Compiler 방식으로 실행합니다.
보통 view 작업을 진행하다 보면, 여러가지 코드가 한 파일에 뒤섞이게 된다. JSP 파일안에 html, css, javascript, java 등의 코드들이 뒤섞에 있다보면 validation이 크게 의미가 없게 되는 경우가 있는데 이럴 경우에는 굳이 validation을 할필요가 없어지게 된다. Validation은 에디터상에서 말그대로 문법에 대한 오류를 실시간으로 검사해 알려주는 것이기 때문에 validation만 해제해도 eclipse 작업속도에 그 만큼의 영향을 미치게 된다.
Window > Preferences > General > Validation > Validator 항목에서 문법검사를 하지 않을 항목에 대해 체크를 해제하면 된다.
소스 자동 폴딩 해제
블록단위로 접혀지는 자동 폴딩을 해제 합니다.
자동 동작하는 코드 자동완성기능 해제
클래스의 변수, 메소드 등을 접근할 때 유용한 기능이지만 자동 동작으로 인해 버벅거리는 원인을 발생하곤 하죠?
이걸 해제한다고 해도 CTRL + SPACE 를 사용해서 동작 시킬 수 있습니다.
불필요한 플러그인 삭제
컴퓨터를 사용하더라도 많은 프로그램들이 깔려 있으면 컴퓨터가 느린것처럼 이클립스 또한 사용하지 않는 플러그인들은 제거하는 것이 좋습니다.
해당 경우는 해당 위치에 RemoteSystemsTempFiles,Server 폴더만 생성해주면
해결이 된다
참고 : http://hunit.tistory.com/193
http://codedragon.tistory.com/5005
+ 2018/01/08 추가
해당 방법을 사용하면 에러는 고쳐지지만
기존에 설정했던 SVN과 GIT 설정등이 있을경우 전부 사라져 버리기때문에
해당 방법 사용전 프로젝트들을 백업 시켜두고
연동된 프로젝트가 있었다면 방법 사용후엔 연결이 끊겨있기때문에
재연결이나 import를 시켜주어야한다
이클립스의 설정은 윈도우 레지스트리에 보관되지 않습니다. 워크스페이스 폴더를 보면 .metadata 폴더가 있습니다. 여기에 이클립스에서 설정했던 내용들이 들어가 있습니다.
.metadata
이 얘기는 workspace를 바꾸면 설정을 다시해 줘야 한다는 뜻입니다. 또한 이클립스를 업그레이드해도 이전에 쓰던 작업환경의 설정을 그대로 가져갈 수 있다는 뜻이기도 합니다.
살짝 .metadata 폴더 내용을 보면 다음과 같습니다.
.metadata 폴더
이 중에 각각의 플러그인 설정값은 .plugins 아래 보관이 됩니다. .log 파일은 이클립스 내부에서 발생하는 오류들의 스택트레이스 로그가 보관됩니다. 플러그인 충돌이나 기타 이클립스가 오작동을 할 경우 이 안에 있는 내용을 토대로 구글링 해보면 운 좋게 해결법을 찾을 수 있습니다.
이클립스가 종료된 상태에서 .metadata 를 지우면 설정은 다시하셔야 됩니다. 이클립스의 검색 인덱스 파일도 여기에 보관이 되기 때문에 혹시나 이클립스 워크스페이스가 무거워졌다고 느껴지면 한 번 지웠다가 다시 설정하는 것도 나쁘지는 않습니다.
이클립스(Eclipse)를 새 PC에 설치해서 구동하려고 했더니, 다음과 같은 오류 메시지가 떴습니다.
이 오류 메시지가 뜨면 이클립스 실행 자체가 되지 않습니다.
회사에서도 그렇고, 이전 PC에서도 그렇고, 별 문제 없이 잘 실행 되었던 것으로 기억하는데..(사실 잘 기억은 안나네요. 처음 설치하고 고생했는지는 너무 오래전 일이라. 보통 한 번 잘 세팅해놓고, 왠만해서는 변경하지 않으니... ㅎㅎㅎ)
Java was started but returned exit code=13 로 시작하는 긴 오류 메시지가 떴습니다. 블라블라~
보통 가장 빈번한 경우는 OS 비트와 이클립스의 지원 비트 버전이 다른 경우입니다.
OS는 64비트인데, 이클립스는 32비트용을 다운로드 받아 설치한 경우이지요.
이 때의 문제는 간단히 이클립스를 OS 버전에 맞는 것으로 다시 다운로드 받아 설치하면 됩니다.
그리고 다른 케이스가 있는데, 이클립스가 실행하면 javaw.exe 파일(JDK 내에 있음)을 찾아 실행시키는데, 해당 파일을 찾지 못한 경우입니다. (제가 겪은 케이스입니다.)
이 때에는 직접 설치한 JDK폴더의 javaw.exe 파일 경로를 eclipse.ini 파일에 지정해주면 됩니다.
참고로 javaw.exe 파일은 java.exe 파일과 그 기능이나 동작은 동일하지만, 단지 Console Window 를 띄우지 않는 다는 차이점만 있습니다. (즉, Java.exe 와 동일하게 동작하지만, 어떠한 상태 정보등을 명령 프롬프트(콘솔 창)에 출력하지 않습니다. 단 오류가 발생하는 경우라면 오류 메시지 박스(대화 상자)를 띄워줍니다.)
그리고 java.exe 파일은 자바 프로그램을 구동시키기 위한 자바 런타임 환경(Java Runtime Environment)을 제공 뿐만 아니라 웹 브라우저에서 Java 기반의 플러그인을 실행할 수 있도록 하기 위한 백그라운드 프로세스로 실행되는 프로그램입니다. 그렇기 때문에 Java 프로그래밍에는 필수 요소입니다.
Eclipse가 설치된 폴더로 가서 eclipse.ini 파일을 메모장 등의 텍스트 편집 도구로 불러옵니다.
그리고 아래와 같이 -vmargs 윗쪽에 javaw.exe 파일 경로를 입력하여 줍니다. 사용자마다 JDK 설치 폴더가 다를테니, 자신의 시스템에 설치된 경로를 확인하여 입력하시면 됩니다.
-vm C:\Java\jdk1.7.0_45\bin\javaw.exe (javaw.exe 파일이 존재하는 경로)
아래 -vmargs 는 -vm (Virtual Machine)으로 구동될 javaw.exe의 인자 정보들을 의미하므로 위의 -vm 코드는 반드시 -vmargs 보다 상단에 작성하여야 합니다.
두 번째 버튼을 눌러 값을 반환받는 상황입니다.
단순히 실행만 하려면 세 번째 버튼을 누릅니다.
