전공공부

위 선을 잘 보면 1 -> 6 -> 12 -> 18 즉, 6의 배수로 늘어나는 규칙을 발견 할 수 있다. 그렇다면 27으로 가기 위해서는 1 + 6*1 + 6*2 + 6*3 = 37 이내이고 1 + 6*1 + 6*2 = 19 이상이다. 그러면 해당 사이인 위치로 가기 위해서는 총 4번을 움직여야 갈 수 있다는 것을 알 수 있다. 13의 경우 : 1 + 6*1 + 6*2 = 19 이내이고 1 + 6*1 = 7 이상이다. 총 3번을 움직여야 갈 수 있다. 이를 구현하면 된다. import java.util.Scanner; public class BOJ_2292_벌집 { public static void main(String[] args) { Scanner sc = new Scanner(System.in); ..

문제에서 어떻게 구현해야 하는지 설명해주니 그대로 문제를 풀이하면 된다. package Simulation; import java.util.Scanner; public class BOJ_5073_삼각형과_세_변{ public static void main(String[] args) { Scanner sc = new Scanner(System.in); while(true){ int a = sc.nextInt(); int b = sc.nextInt(); int c = sc.nextInt(); if(a == 0 && b == 0 && c == 0){ return; } int max = Math.max(a, Math.max(a, c)); System.out.println(change(max, a, b, c));..

OS Thread Scheduler 여러 스레드가 실행 중이면 운영체제의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할지 정한다. 정상적인 운영체제라면 이 작업을 공정하게 수행하지만 구체적인 스케줄링 정책은 운영체제마다 다를 수 있다. 따라서 잘 작성된 프로그램이라면 이 정책에 좌지우지돼서는 안된다. (OS에 따라서 성능이 달라지면 안됌.) 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다. 견고하고 이식성이 좋은 프로그램을 만드는 법 해결방법 : 실행가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 설계해야 한다. 그러면, 실행가능한 스레드의 수를 적게 유지하는 방법은 없을까? 각 스레드가 일을 마치면 다음 일거리가 생길때 까지 대..

n + 1, m+1 만큼 자리를 띄워서 앉아야 하므로 덧샘을 진행하고 H,W에 대해서 크기를 거기서 나눈 만큼이 남는 크기가 되는데 n+1,m+1로 만들었을때 사각형 외의 부분에도 실제로 사람이 앉을 수 있으므로 Math.ceil을 통해서 남는 자리는 반올림 해버린다. import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; import java.util.*; public class BOJ_23971_ZOAC4 { public static void main(String[] args) throws IOException{ BufferedReader in = new BufferedReader(new I..

과도한 동기화의 문제 충분하지 못한 동기화도 문제이지만 과도한 동기화도 문제다. 성능을 떨어뜨리고 교착상태(Deadlock)에 빠질 수 있으며 심지어 응답 불가나 잘못된 결과를 계산해내는 안전 실패(safety failure)를 일으킬 수 있다. 응답 불가와 안전 실패를 피하려면 동기화 메서드와 동기화 블록 안에서는 제어를 절대로 클라이언트에 양도하면 안 된다. 1. 동기화된 블록 안에서는 재정의 가능한 메서드 2. 클라이언트가 넘겨준 함수 객체를 동기화 메서드 내부에서 호출 무슨 일을 할지 모르기 때문에 예외를 발생시키거나, 교착상태를 만들거나, 데이터를 훼손할 수 있다. 위와 같은 메서드를 외계인 메서드(alien method)라고 한다. 외계인 메서드 예시 코드 동기화 블럭 내부에서 외계인 코드를 ..

검사 예외의 문서화 검사 예외는 (RuntimeException 및 Error를 제외한 예외들) 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 통하여 정확히 문서화하자. 극단적인 예로 메서드가 Exception이나 Throwable을 던진다고 선언해서는 안된다. 이렇게 선언해버리면 API 사용성을 크게 떨어트릴 수 있다. (상세 예외 케이스를 내어주지 못하니 대처가 힘듦) 위 규칙에는 예외가 있는데 바로 main 메서드이다. JVM에서만 호출하므로 Exception을 던져도 무방하다. 비검사 예외의 문서화 비검사 예외도 정성껏 문서화하면 좋다. 프로그래밍을 하면서 나는 프로그래밍 오류들이 비검사예외인데 이러한 상황을 맞딱트릴 수 있다고 API에서 먼저 문서화 해두면 코..

호출하는 쪽에서 복구 할 수 있는 상황이라면 검사 예외를 사용하자 검사 예외를 사용하면 호출자가 그 예외를 catch로 잡아서 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자 비검사 throwable은 두 가지로 런타임 예외와 에러다. 비검사 예외나 에러는 복구가 불가능한 경우나 더 실행해봐야 득보다는 실이 많은 경우에 사용한다. 여기서, 런타임 예외의 대부분은 단순히 클라이언트가 API 명세를 따르지 않아서 일어나는 예외이다. 위 상황에 대한 예는 ArrayIndexOutOfBoundsException 으로 쉽게 설명이 가능하다. 배열의 인덱스는 적어도 0에서 시작하고 '배열 길이 -1' 사이여야 한다. 하지만, 이때 ArrayIndexOutOfB..

컬랙션이 비었을 때 null을 반환하는 메서드를 보자 private final List cheesesInStock = ...; /** * @return 매장 안의 모든 치즈 목록을 반환한다. * 단, 재고가 하나도 없다면 null을 반환한다. */ public List getCheeses() { return cheesesInStock.isEmtpy() ? null : new ArrayList(cheesesInStock); } 해당 코드의 문제점은 클라이언트가 null 상황을 처리하는 코드를 추가로 작성해야 한다. List cheeses = shop.getCheeses(); if(cheeses != null && cheeses.contains(Cheese.STILTON)) System.out.println..