Description :
Spring MVC is the core component of the Spring Framework's web
strategy. It provides a robust, flexible framework for building web
applications built on the Model 2 architecture. In this presentation,
Bob McCune will provide an overview of the new features and
capabilities of Spring MVC including its @Controller annotations, REST
support, and new data validation integrations.
Effective Java에 나오는 내용이긴 합니다만, 우리가 자주 저지르는 실수가 있습니다.
프로그램을 하다가 보면 자주 난수(Random number)를 발생시켜야 할 때가 있습니다.
아래와 같은 코드를 사용하여 많이 발생을 시키죠.
private static final Random rnd = new Random();
static int random(int n) {
return Math.abs(rnd.nextInt()) % n;
}
논리적으로는 아무런 문제가 없어 보입니다.
그렇지만 실제적으로 다음과 같은 코드를 사용하여 테스트를 해보도록 합시다.
public static void main(String[] args) {
int n = 2 * (Integer.MAX_VALUE / 3);
int low = 0;
for (int i = 0; i < 1000000; i++)
if (random(n) < n/2)
low++;
System.out.println(low);
}
위의 코드데로라면 100만번 테스트를 해서 기준값보다 작은 수가 나오는 경우는 50% 가깝게 나와야 정상입니다.
그렇지만 실제로 돌려보면 항상 666,666에 가까운 수가 나옵니다.
난수가 제대로 발생하고 있지 않다는 이야기죠.
실제적으로 이런식의 버그는 찾아내기가 쉽지 않습니다.
로직상으로는 아무런 문제가 없기 때문이죠.
따라서 저런 프로그램으로 Load Balancing하거나 데이터를 분산하고 있다면 제대로 처리가 되고 있지 않을 것입니다.
java 1.2부터 추가된 Random.nextInt(int) 를 사용하거나, apache commons의 RandomUtils.nextInt()를 사용해야 제대로 동작을 합니다.
Effective Java 3nd Edition을 회사사람들과 함께 스터디하는 중에 보게된 명언들이다.
More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason—including blind stupidity. —William A. Wulf [Wulf72]
( 맹목적인 어리석음을 포함한 다양한 이유중에 죄악같은 프로그램을 행하게 되는 으뜸의 이유는 바로 efficiency라는 이름으로 행하여 지게 된다, )
We should forget about small efficiencies, say about 97% of the time: premature
optimization is the root of all evil.
—Donald E. Knuth [Knuth74]( 작은 효율성따위는 잊어버려야 한다, 어설픈 Optimization은 모든 악의 근원이다)
We follow two rules in the matter of optimization:
Rule 1. Don’t do it.
Rule 2 (for experts only). Don’t do it yet—that is, not until you have a
perfectly clear and unoptimized solution.
—M. A. Jackson [Jackson75 ] ( Optimization문제에 대하여 두가지 원칙을 따라야 한다. 첫번째는 하지 말라.두번째도 하지 말라이다. 단, 전문가의 경우, 당신의 솔루션이 명백하게 unoptimized되어있다는것이 명백해 지기 전까지는 절대 하지 말아라.)
약간의 의역과 오역이 있을수 있다;; 즉 결론은 잘 모르면서 성능 튜닝이나 Optimization을 하지 말라는 이야기다.
절대적으로 맞는 말이다.
내가 하는일이 어떤 결과를 나을지 어느정도 예측이 불가능하다면 하지 않는 편이 더 나은 경우를 많이 보아왔다.
또한 성능상의 이유로 좋은 아키텍처를 포기하지 말라는 말도 빼먹지 않고 있다.
Don’t sacrifice sound architectural principles for performance. Strive to write good programs rather than fast ones
아 결혼도 곧 합니다. 연락드립죠. ㅎㅎ
댓글을 달아 주세요