모든 빌드에는 3-4 초가 추가로 걸리므로 로그 출력 후에 다음이 인쇄됩니다.왜 Kotlin 소스 코드의 Gradle 빌드가 ~ 3 초 동안 일시 중지되어 "System.gc()"을 강제 실행합니까?
[생활사] [org.jetbrains.kotlin.gradle.plugin.KotlinGradleBuildServices] 왜이 "강요"입니다
으로 System.gc()를 강제로? 이것을 피하고 빌드 속도를 높이려면 어떻게해야합니까?
이 문제를 조사한 결과, Gradle의 디버그 수준 로깅을 (예 : gradle --debug assemble)으로 설정 한 결과입니다.
디버그 로깅을 사용하지 않고 실행하십시오. (예 : gradle --info assemble)이며 더 이상 발생하지 않아야합니다.
참고 : 이전과 이후 System.gc를 호출 플러그인 libraries/tools/kotlin-gradle-plugin/src/main/kotlin/org/jetbrains/kotlin/gradle/plugin/KotlinGradleBuildServices.kt
코 틀린 Gradle을 디버그 로깅 (Gradle을가 -d 또는 --debug 명령 행 인수와 함께 실행됩니다) 활성화 된 경우에만 빌드. 사용자는 대개 시끄 럽고 느리기 때문에 디버그 로깅을 활성화하여 Gradle을 실행하지 않으므로 GC를 강제 실행하는 것이 상대적으로 사소한 문제입니다.
이전에는이 동작이 Gradle 데몬이 활성화되었을 때 메모리 누수를 테스트하기 위해 추가되었습니다. 아이디어는 빌드 전후에 사용 된 메모리의 차이를 기록하고 결과적으로 테스트에서 몇 가지 빌드를 실행하고 그 차이가 임계 값을 초과하지 않는다고 주장하는 것이 었습니다. 내가 System.gc를 호출 생각
는 KotlinGradleIT#testKotlinOnlyDaemonMemory가 실행되는 테스트하지 않는 한 피해야한다, 그래서 나는 그들이하지 않는 자신의 디버깅 목표를 달성 할 수있는 방법을 지적 https://youtrack.jetbrains.com/issue/KT-17960
감사 bugtracker 코 틀린에 문제를 만들었습니다 나 자신과 같은 새로운 Gradle 사용자를 늪지. 빌드가 길어질 수 있고, 왜 Gradle이 결정을 내리는 지 알아내는 유일한 방법은'--debug'를 사용하는 것입니다. 나는 그 출력물을 디스크에 버리고 현재 상당히 많이 의존하고 있습니다. 그들이 모든 사용자 빌드에서 실행되는 메모리 진단없이 살아갈 수 있다고 동의하면 3 초 더 행복해집니다. (YouTrack 문제에 대해 투표) – naki