在[NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil error:nil]中泄漏泄漏

Question

我在 returnData = [NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil error:nil];

以下是我正在使用的代码

    NSString* curl = @"https://Some Url?ticket=";
curl = [curl stringByAppendingString:self.ticket];
curl = [curl stringByAppendingString:@"&apikey=hjgajgfjaghjf&XMLString="];
curl = [curl stringByAppendingString:stringB];
curl = [curl stringByReplacingOccurrencesOfString:@"\n" withString:@""];
NSURL *finalURL = [NSURL URLWithString:curl];

    NSMutableURLRequest *theRequest = [NSMutableURLRequest requestWithURL:finalURL cachePolicy:NSURLRequestReloadIgnoringCacheData   timeoutInterval:10]; 
     [theRequest setHTTPMethod:@"POST"];

   NSData* returnData= [NSURLConnection sendSynchronousRequest:theRequest returningResponse:nil error:nil];

任何一个可以告诉我为什么我在得到泄漏returndata我relased的returndata并尝试过,但我仍得到.

谢谢

Answer 1

从您发布的代码中,没有泄漏.当你最终返回returnData时,调用者可能会保留它并忘记释放它,但是你提供的代码片段中的所有对象都是自动释放的,并且将在当前runloop的末尾释放.

我能想到的一些事情:

1. 你是否可能在后台线程中运行它(通过performSelectorInBackground:withObject:或使用显式的NSThread分配)并忘记创建并随后在代码周围排出NSAutoreleasePool？

2. 您可能在NSURLConnection的缓存中占用了内存.您没有提到导致您认为returnData被泄露的原因,但如果它只是该区域内存丢失(而不是专门标记returnData对象的Leaks Instrument),那么您可以通过清除NSURLConnection显式缓存类似于[[NSURLCache sharedURLCache] removeAllCachedResponses];

3. 虽然与那里的任何实际泄漏无关,但使用NSString-stringWithFormat:而不是多次调用来构建URL字符串会稍微高效一些-stringByAppendingString:.同样,所有内容都是自动释放的,因此字符串处理中没有泄漏,但是您会在下一个NSAutoreleasePool消耗之前创建更少的临时对象并减少峰值内存使用量.

我寻找解决方案的第一个地方是这个代码的调用者.赔率很高,它保留了这种方法的返回值,并且在某些时候没有正确地释放它.它也可以将返回分配给一个保留@property而不是最终nil'ing属性在-dealloc仪器将告诉你泄漏内存的位置首先分配,但它无法知道泄漏实际发生的位置 - 当最后包含指针的变量将被覆盖或超出范围.

如果您还没有,请尝试使用Xcode的Build and Analyze功能编译代码.由该函数运行的CLANG静态分析器通常可以计算出最后一个引用丢失的位置,而不是仪器中的运行时动态分析.

跟踪这个下来好运!泄漏永远不会有趣....