Java 스레드 풀 사용 요약

최근 프로젝트에서 SQL 쿼리를 자주 사용하고, 파일을 작성하고, 하위 작업을 분할해야 하는 상황에 직면했습니다. 프로그램 처리량을 향상시키기 위해 스레드 풀을 사용합니다.

처음에는 사용자 수에 따라 샤딩하는 것을 고려하세요. 데이터베이스 쿼리에서는 Oracle의 () 위치에 대한 쿼리가 1,000개 이하로 제한되므로 900명의 사용자를 하나의 조각으로 나누는 것을 고려하세요. 작업을 수행하고 처리를 위해 수정 스레드 풀로 전달됩니다.

그러나 각 작업에는 쿠폰 쿼리와 작성할 댓글 수 쿼리라는 두 가지 더 큰 하위 작업이 있습니다. 이 두 하위 작업에는 많은 수의 SQL 쿼리가 필요하므로 이 두 하위 작업을 작업으로 캡슐화하는 것을 고려했습니다. 처리를 위해 스레드 풀로 이동합니다. 그러나 메인 작업의 실행은 하위 작업의 결과에 따라 달라지기 때문에 동일한 스레드 풀을 사용하는 경우 하위 작업이 제출된 후에도 작업 대기열에서 실행될 작업은 여전히 ​​메인 작업이고 CPU는 먼저 제출된 기본 작업에서 Future.get을 기다리는 중()이 반환되면 하위 작업은 실행할 CPU 리소스를 얻을 수 없으며 작업 대기열에서 기다리고 있으므로 프로그램이 종료될 때까지 기다리게 됩니다. 따라서 제출된 작업이 CPU 시간을 얻고 항상 대기열에서 기다리지 않기를 바라면서 스레드 풀이 수정에서 캐시로 변경되었습니다. 나중에 이로 인해 문제가 발생했는데, 이에 대해서는 다음 기사에서 설명하겠습니다.

사용자의 청구서 데이터를 계산할 때 템플릿 센터를 호출하여 이메일을 생성해야 하며, 생성된 이메일을 디스크에 저장해야 합니다. 이는 두 가지 IO 집약적인 작업입니다. 하나는 켜져 있습니다. 소켓 대기 중, 하나는 로컬 io에서 기다리고 있습니다. 캐시 스레드 풀에 계속 제출하면 스레드 풀은 각 작업에 대해 스레드를 생성하므로 많은 리소스를 소비하게 되고 CPU는 스레드를 자주 전환하여 프로그램의 처리량을 감소시킵니다. 따라서 새 수정 스레드 풀을 생성하고 처리를 위해 이러한 후속 작업을 수정 스레드 풀에 제출합니다. 스레드 풀은 고정된 수의 작업을 실행하여 프로그램이 다른 차단 조건에서 계속 실행될 수 있도록 하고 오류 생성을 방지합니다. 스레드 자원이 많이 낭비됩니다.

실제로 최종 프로그램에서는 5개의 스레드 풀이 사용되었습니다. 계층적으로 사용하는 이유는 다음과 같습니다.

프로그램 실행의 효율성을 높이기 위해 사용자를 다음과 같이 분류할 수 있습니다. 한 조각을 샤딩하고 각 작업에는 데이터베이스에 자주 쿼리하는 두 개의 하위 작업이 포함됩니다. 각 조각이 처리된 후 이메일을 생성하려면 네트워크 IO가 필요하고 이메일을 저장하려면 디스크 IO가 필요합니다. 동일한 스레드 풀을 사용하는 경우 상위 작업에서 생성된 하위 작업이 수정 스레드 풀에 제출된 후 작업 대기열이 여전히 상위 작업에 의해 점유되어 있기 때문에 다양한 유형의 IO 작업이 작업 대기열에서 대기하게 됩니다. 시스템 처리량을 향상시킵니다. 하위 수준 작업을 다른 스레드 풀에 제출한 후 하위 수준 작업은 즉시 실행되고 네트워크 IO 및 디스크 읽기 및 쓰기를 수행할 수 있어 운영 효율성이 향상됩니다.