Integration 모듈 메서드 지역 StringBuffer 13곳 → StringBuilder (불필요한 동기화 제거)

[EricSeokgon]

문제

Integration 모듈(itl.integration·itl.webservice)의 StringBuffer 사용 13곳이 전부 메서드 지역 변수입니다. 다른 스레드로 공개되지 않으므로 StringBuffer의 메서드 동기화(synchronized)는 얻는 것 없이 비용만 발생합니다.

• toString() 계열 9곳: SystemDefinition, IntegrationDefinition, OrganizationDefinition, RecordTypeDefinition, RecordTypeFieldDefinition, ServiceDefinition (itl.integration.metadata) / MappingInfo, WebServiceClientDefinition, WebServiceServerDefinition (itl.webservice.data)
• EgovWebServiceClassLoaderImpl 4곳: 메서드 디스크립터·시그니처 조립(desc, signature) — 웹서비스 클래스 동적 생성 경로

전수 확인 결과 필드 선언·메서드 파라미터·반환 타입에 StringBuffer가 쓰인 곳은 0건으로, 모두 생성 후 같은 메서드 안에서 toString()으로 끝나는 지역 버퍼입니다.

수정

13곳 모두 StringBuilder로 전환했습니다 (10개 파일, +13 −13). 로직·출력 문자열 변화 없음.

검증

1) 빌드 — JDK 17.0.19 / Maven 3.9.9, 의존 모듈(egovframe-rte-fdl-logging 5.0.0) 로컬 install 후:

• org.egovframe.rte.itl.integration : BUILD SUCCESS
• org.egovframe.rte.itl.webservice : BUILD SUCCESS

2) 성능 (마이크로벤치, 200만 회 반복 · 워밍업 30만 회, JDK 17.0.19) — 수치를 있는 그대로 싣습니다:

시나리오	StringBuffer ns/op	StringBuilder ns/op	개선
toString() 유형 (append 10회)	337~411	305~329	10~20% 단축
descriptor 조립 유형 (append 30회)	1,000~1,015	926~941	6~9% 단축

JIT의 락 최적화 덕분에 단일 스레드 환경의 이득은 수십 % 수준으로 크지 않습니다. 이 PR의 주된 근거는 극적인 속도 향상보다 의미 없는 동기화 제거와 관례 정합(지역 버퍼는 StringBuilder)이며, 성능은 부수 효과로 이해해 주시면 좋겠습니다.

영향

• 동작·출력 변화 없음, 공개 API 변화 없음
• 스레드 안전성 영향 없음 — 13곳 모두 지역 변수임을 전수 확인
• 변경 범위: 10개 파일 26개 토큰 (+13 −13)