25G.story

JIT 세가지 버전 32-bit 클라이언트 버전 32-bit 서버 버전 64-bit 서버 버전 64-bit 서버 컴파일러는 티어드 컴파일을 지원하기 위해 클라이언트 컴파일도 가지고 있습니다. 32bit 운영체제를 가지고 있다면 JVM도 32bit를 사용해야 합니다. 64bit 운영체제를 가지고 있다면 JVM은 32bit 또는 64bit를 사용할 수 있습니다. 만약 힙 크기가 3GB보다 작다면 32bit 버전의 자바가 더 빠르게 동작할 수 있습니다. 당연하게 메모리 참조가 32bit 이므로 64bit 보다는 비용이 싸기 때문입니다. 만약 long이나 double 같은 64bit 변수를 광범위하게 사용하는게 아니고 전체 프로세스 크기가 4GB 미만이라면 32bit 컴파일러를 사용하는게 더 성능상의 우위가 있..

기본 튜닝 JIT 컴파일러는 두가지 형태로 나뉩니다. 사용할 형태는 흔히 애플리케이션이 실행되고 있을때 해야할 컴파일러 튜닝에 따라 결정됩니다. 두개의 컴파일러는 클라이언트와 서버로 알려져 있습니다. JVM 개발자 들은 흔히 c1(컴파일러 1, 클라이언트 컴파일러) 와 c2(컴파일러 2, 서버 컴파일러) 라는 이름으로 부릅니다. 두 컴파일러의 주요 차이점은 코드 컴파일에 있어서의 적극성 유무입니다. 클라이언트 컴파일러 서버 컴파일러보다 먼저 컴파일을 하기 시작합니다. 이는 서버 컴파일러보다 상대적으로 많은 코드를 컴파일한다는 의미이며 코드가 실행되기 시작하는 시간동안 클라이언트 컴파일러가 보다 더 빠를것입니다. 서버 컴파일러 클라이어트 컴파일러보다 더 많은 정보를 바탕으로 컴파일을 하고 더 나은 최적화를..

핫스팟 컴파일 핫스팟이란 이름은 코드 컴파일에 대한 접근법에서 유래했다고 합니다. 일반적인 프로그램은 전체 코드 중 일부만 자주 실행되며 애플리케이션의 성능은 이 일부가 얼마나 빠르게 실행되는가에 의해 좌우됩니다. 이 중요한 영역을 애플리케이션의 핫 스팟 이라고 합니다. 해당 영역의 코드가 많이 실행될 수 록 더욱 핫해집니다. 이런이유로 JVM은 코드를 실행할 때 바로 코드 컴파일을 하지 않습니다. 여기에는 기본적인 이유가 두가지가 있습니다. 코드가 한번만 실행된다면 컴파일은 헛수고가 됩니다. 컴파일해서 컴파일된 코드를 한번만 실행하는 것 보다 자바 바이트 코드를 인터프리트하는 편이 더 빠를 것입니다. 최적화 때문입니다. JVM이 특정 메소드나 루프를 실행하는 시간이 길어질 수록 코드에대해 얻어지는 정보..

JIT 컴파일러란? JIT (just-in-time,JIT) 컴파일러는 JVM의 핵심입니다. JVM내에서 컴파일러보다 성능에 더 영향을 주는 요소는 없습니다. 대부분의 상황에서 티어드 컴파일(tiered compilation)을 사용하기만 해도 튜닝할 필요는 거의 없습니다. 컴파일과 인터프리트 CPU는 어셈블리나 바이너리 코드라고 불리는 특정 명령어만 실행시킬 수 있습니다. 그 말은 CPU가 실행하는 모든 프로그램은 이 명령어 들로 변환이 가능합니다. C++같은 언어들은 바이너리로 컴파일된 코드로 실행되어 컴파일형 언어라고 불립니다. 즉 프로그램이 작성되고 정적 컴파일러는 바이너리를 생성합니다. 그 바이너리 내의 어셈블리 코드는 특정 CPU만을 대상으로 합니다. 반면 PHP나 Perl과 같은 언어는 인터..

String text = "안녕하세요"; String [] charSet = {"utf-8","euc-kr","ksc5601","iso-8859-1","x-windows-949"}; for (int i=0; i

Jpa를 사용하다 보면 update를 할 때 dto에 @Valid를 활용해서 밸리데이션 체크를 하기도 애매하고 api서버로써 클라이언트와 통신을 하다 보면 리 엑트에서 undifind로 필드조차도 보내지지 않거나 null값이 들어가는 것을 서버에서 체크해줄 필요가 있다. 그런데 문제는 너무 귀찮다는 것입니다. 필드마다 null체크를 해서 setter로 더티 체킹을 유도하는 작업이 update시에 굉장히 귀찮고 피곤했습니다. 그래서 다음과 같은 util class를 만들어 봤습니다./** * update시에 null과 field가 없는 것을 체크해서 dto에 데이터가 있는부분만 entity 객체에 입혀주는 util class */public class DtoFieldEmptyChecker { publ..

Maven 과 Gradle manen xml 기반 프로젝트 의존성 관리 도구 해당 라이브러리를 사용하기 위한 다른라이브러리까지 저장소에서 다운받아 준다. 전체적인 라이프사이클 관리 도구 Maven Lifecycle Clean : 이전 빌드에서 생성된 파일들을 삭제하는 단계 Validate : 프로젝트가 올바른지 확인학고 필요한 모든 정보를 사용할 수 있는 지 확인하는 단계 Compile : 프로젝트의 소스코드를 컴파일하는 단계 Test : 유닛(단위) 테스트를 수행하는 단계(테스트 실패시 빌드 실패로 처리, 스킵 가능) Package : 실제 컴파일된 소스 코드와 리소스들을 jar등의 배포를 위한 패키지로 만드는 단계 Verify : 통합테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는..

@Transient db에 컬럼이 만들어지지 않게 하고 싶을 때 사용하는 어노테이션입니다. 뷰에 렌더링할때 칼럼에 필요 없거나 추가하면 문제가 생기는 데이터지만 값을 뷰로 들고 가야 하는 경우가 있다. 이럴 때 javax.persistece가 들고 있는 Transient어노테이션을 사용하면 DB에 컬럼을 만들지 않고도 변수를 담아서 데이터를 뷰로 들고 갈 수 있습니다.

지금 현재 하고 있는 프로젝트에서 페이징 처리를 해 보려고 합니다. 위 어노테이션을 사용해서 spring에서 페이징처리를 할 수 있습니다. 다음과 같이 페이징 할 설정들을 어노테이션에 달아주고 해당 객체를 Service를 하는 곳으로 던져 준다. 이때 List가 아닌 Page타입으로! Service단에서 받아주고 repository를 사용해서 호출하는 메서드도 위 상황과 코드에 맞게 수정해 준다. 이렇게만 설정해 주면 내부적으로 Spring이 알아서 페이징 처리를 해 주는데 postman으로 테스트를 해보면 다음과 같은 데이터가 넘어온다. data내부에 content안에 있다. (데이터를 뿌려줄때 이 구조로 돼 있지 않으면 데이터가 view에서 보일 수 없다.) 그리고 데이터를 보다 보면 pageable..

QLRM라이브러리 사용해서 DTO를 매핑해 보겠습니다. QLRM라이브러리 의존성 org.qlrm qlrm 2.1.1 QLRM라이브러리란?? qlrm은 DB에서 Result 된 결과를 자바 클래스에 메핑 해주는 라이브러리. QLRM를 사용하는 이유 다음과같은 쿼리는 모델의 형태로 리턴 받을 수 없고 DTO로 받아내야 하는 쿼리다. 이처럼 DTO로 받아 내야 하는 쿼리라면 JPARepository를 상속받은 인터페이스로 native쿼리를 짜서 날릴 수 없다. 왜냐하면 상속받은 클래스 타입의 모델만 리턴을 해주기 때문. 그렇기 때문에 DTO로 DB에서 결과를 받아야하면 JPARepository를 사용할 수 없다. 기능예시 그래서 @Service단에서 직접 쿼리를 짜서 던져야한다. 주석이 중요한 내용이고 코드는..