티스토리 뷰


IO에서 발생하는 시간은 CPU의 대기시간에 속하기 때문에 성능에 가장 큰 영향을 끼친다.

IO를 효율적으로 사용하기 위해서는



1. 버퍼를 잘 사용하자
BufferedReader 등 버퍼를 사용하는 클래스들도 있다.
잘 보고 사용하자



2. 요청이 발생할 때마다 파일을 읽어선 안됀다.

모든 요청이 올 때마다 파일을 읽도록 한다면 엄청난 IO가 발생할 것이고 이는 성능의 저하를 야기한다.

또한 병목현상이 발생할 확률도 높다.

보통 DB의 쿼리나 여러 설정들을 파일에 저장하고 사용하는 경우가 많은데

이 경우 이 파일들을 미리 읽어놓고 사용하는 것이 좋으며, 

수정될 때마다 어플리케이션을 재시작하는 것이 번거롭다면, 

별도의 스레드를 생성하여 5~10분 주기로 수정여부를 확인해주는 것도 좋다.


예를 들어보자면 mybatis 프레임워크는 쿼리파일을 xml로 빼놓고 사용한다.

하지만 xml파일을 변경한다고 해도 WAS 리로드를 하지 않는 이상 변경된 내용이 적용되지 않는다.

이를 볼때 mybatis도 요청이 올때마다 파일을 읽는 것이 아닌 미리 읽어 메모리상에 올려둔다는 것을 알 수 있다.



3. NIO를 사용하자

기존 자바의 IO는 자바가 커널에게 파일을 읽어달라고 요청하여 커널의 버퍼에 있는 데이터를

JVM으로 전달받아 사용했었다. 하지만 JDK 1.4때 추가된 NIO는 이를 자바에서 직접 통제하여

시간을 단축할 수 있게 되었다. 또한 JDK 7.0에서 추가된 NIO2도 있다.



4. NIO : DirectByteBuffer 객체를 여러번 생성하지 말자

ByteBuffer 객체를 생성할 때 사용되는 allocateDirect() 메소드에서 반환되는 타입인 

DirectByteBuffer 객체를 생성하는 경우엔 가능하면 singleton 패턴을 사용하여

하나의 객체만 생성하는 것이 좋다.

왜냐하면 DirectByteBuffer의 생성자에 포함된 코드중 System.gc() 메소드를 포함한 코드가

있기 때문에 생성자가 자주 호출된 경우에는 GC가 자주 발생하고, 이는 성능에 악영향을 끼친다.



5. File 클래스의 lastModified() 메소드는 사용을 지양하자

이 메소드는 내부 구조를 보면 처리되는 절차가 복잡하다. 메소드 자체의 수행시간은 얼마 되지 않지만,

이 작업은 IO작업을 동반하기 때문에 OS의 IO의 영향을 많이 받는다.

JDK 7.0에서 추가된 Watch관련 클래스를 사용하면 더 쉽게 파일을 모니터링 할 수 있다.

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2025/06   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30
글 보관함