우리 프로젝트에는 GWT 모듈이 있습니다. 최근에 주요 메모리 오버로드가 있었고 그 중 하나는 StackTraceDeobfuscator.javaConcurrentHashMap<String, HashMap<String, String>> symbolMaps 필드에 저장된 120MB 개체였습니다. 그것은 무엇이며 무엇을위한 것입니까?심볼 캐시 맵은 120MB입니다. 무엇이며 무엇이 포함되어 있습니까?
"과부하"가 발생한 시점에서지도가 포함 된 16 개의 세그먼트 중 1 위는 59MB이고 2 위는 30MB이고 3 위는 29.9MB였습니다.
필자가 이해하는 한, 코드가 복잡해지고 stacktraces를 저장한다는 사실과 관련이 있지만, 누군가 더 자세히 설명해 줄 수 있습니까? 그것은 거대한 stacktraces와 너무 많은 예외가 있었고 그들은 모두 캐시에 들어갔 을까? 그러나 120MB는 여전히 거대합니다.
GWT는 클라이언트 측에서 다운로드가 더 빠르고 JavaScript 해석이 더 신속하도록 최소한의 JavaScript 코드를 생성하려고 시도합니다. 여기에는 Java 소스에서 사용되는 식별자를 가능한 가장 짧은 식별자로 단축하는 것이 포함됩니다. 분명히 생성 된 짧은 식별자 이름은 (사람에게)별로 유용하지 않습니다.
오류가 발생하면 오류 메시지와 스택 추적에 유용한 정보가 포함되지 않습니다. 그 목적을 위해 resymbolizitaion이 구현되었습니다. 심볼 맵은 컴파일러 인수가 -extra 인 경우 GWT 컴파일러 (컴파일 타임)에서 생성됩니다. 이 심볼 맵에는 생성 된 짧은 식별자에서 원래 Java 식별자로의 매핑이 포함되어 있으므로 오류가 발생하면 원래 이름을 재현 할 수 있습니다 (심볼 맵에서 간단히 조회).
당신은 여기에 대한 자세한 내용을보실 수 있습니다 : Resymbolization/Deobfuscation
내가 사용하지 않는 기호는 프로덕션 배포에 매핑합니다. symbolMaps 디렉토리는 전쟁 컴파일시 제외됩니다. <exclude name="WEB-INF/deploy/**" />. 그러나 최근에는 gwt-log에 의해 제공되는 원격 로깅 기능에 대해 deofuscation을 테스트했습니다.
기호 맵은 -deploy "path" 컴파일 플래그로 생성 될 수 있습니다. gwt.xml에 <collapse-all-properties />을 사용하는 경우이 플래그는 무시됩니다.
그래, "무거운"정보가 120MB의 가중치를 얻었습니까? – niralittle
심볼 맵은 소스 코드뿐만 아니라 GWT 라이브러리에서 사용되는 코드에서도 생성 된 매핑을 포함합니다. 또한 여러 브라우저 용으로 컴파일 된 코드에 가장 적합합니다. – icza
그리고 그로부터 많은 기억이 필요하다는 것은 정상입니까? – niralittle