Microsoft UCMA : 가비지 수집되지 않는 문자열

세션에 레코더 참가자를 추가하는 클라이언트로 작동하는 UCMA 응용 프로그램에서 메모리 프로파일 러를 실행 중입니다. 메모리를 많이 차지하는 문자열 인스턴스가 있음을 알 수 있습니다 (참가자가 제거 되더라도 비활성 잠시 후 나는이 문자열) 수집 된 쓰레기를하지 않는주의 사항 :Microsoft UCMA : 가비지 수집되지 않는 문자열

Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.DiagnosticsInformation..ctor(int,DiagnosticVisibility) 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.DiagnosticsInformation.CreateOutgoingDiagnosticsInformation(uint) 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Collaboration.Call.SignalingSession_StateChanged(object,SignalingStateChangedEventArgs) 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.EventWorkitem<TEventArgs>.Process() 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.WorkitemQueue.ProcessItems() 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.SerializationQueue<T>.ResumeProcessing() 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.SerializationQueue<T>.ResumeProcessingCallback(object) 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.QueueWorkItemState.ExecuteWrappedMethod(WaitCallback,object) 
mscorlib!System.Threading.ExecutionContext.Run(ExecutionContext,ContextCallback,object) 
mscorlib!System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback) 
mscorlib!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(object)

는이 같은 약 2000 인스턴스를 참조하고는 정리되지 않은 것입니다. 누구든지 전에 이것을 보았고 그 원인이 무엇인지 또는 이것이 프레임 워크 자체의 UCMA 문제인지 알고 있습니다.

편집 : (? XML 디시리얼라이저 개체 정리되지 않은) 나는 또한 프레임 워크를 직렬화 많이 볼

System.Xml!System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader,string,XmlDeserializationEvents) 
System.Xml!System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader,string) 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.XmlHelper.DeserializeObjectFragment(byte[],XmlSerializer) 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Collaboration.Conferencing.ConferenceJoinCommandResponse.TryProcessResponseCore(SipMessageData,ref RealTimeException) 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Collaboration.Conferencing.EstablishFocusSessionsAsyncResult.ParticipateCallback(IAsyncResult) 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.CompletionCallbackWorkItem.Microsoft.Rtc.Signaling.IWorkitem.Process() 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.WorkitemQueue.ProcessItems() 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.SerializationQueue<T>.ResumeProcessing() 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.SerializationQueue<T>.ResumeProcessingCallback(object) 
Microsoft.Rtc.Collaboration!Microsoft.Rtc.Signaling.QueueWorkItemState.ExecuteWrappedMethod(WaitCallback,object) 
mscorlib!System.Threading.ExecutionContext.Run(ExecutionContext,ContextCallback,object) 
mscorlib!System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback) 
mscorlib!System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(object)

출처

2013-05-10 Alexandru

쓰레기 수집은 some time of inactivity에 의해 트리거되지 않습니다. 메모리에 문자열이나 다른 클래스의 인스턴스를 많이 보아도 아무런 문제가 없습니다. 그리고 내부 문자열 (컴파일 타임 상수)은 절대로 수집되지 않습니다.

Out-of-Memory 예외가 발생할 때까지 메모리 누수가 발생하지 않습니다.

출처

2013-05-10 13:40:52

하지만 메모리가 올라가고 ... 그 과정에서 내려 오지 않는다면 어떻게 될까요? ... 그리고 그 프로세스를 프로파일 링하면 ... 찍은 스냅 샷에서 3000 개의 새 인스턴스가 표시되고 처음 실행 된 스냅 샷과 비교되며 하루 후 Gen # 2 가비지 수집 호출 이후 더 이상 활동이 없으면 문자열 유형의 인스턴스가 50 개 뿐이며 나머지는 메모리에 저장되어 수백 MB의 RAM을 차지하며 작업 관리자에서 쉽게 볼 수 있습니다. 메모리 누출이 아니겠습니까? – Alexandru

아니요. 실제 메모리 누수는 GC로조차 가능하지 않습니다. 참고 문헌을 잘못 관리 할 수도 있지만 프로그램 논리의 문제입니다. OOM이 보이지 않는 한 문제는 무엇입니까? 메모리는 저렴하고 가상입니다. –

Microsoft UCMA : 가비지 수집되지 않는 문자열

답변

관련 문제