你这个有两个问题，
第一：多线程你这个方法不能保证多线程安全，加锁影响效率。
第二：内存占用吃不消。

你的错误想法：
内存释放的理解有根本错误，再看看书吧。

推荐：
切到串型队列，存储一部分数据后写盘，或者持续写盘。

现在还有问这个的。有意思。

@w99wen 确实想过串行的方法，把初始化和 dict 的操作都挪到串行队列里面去。主要问题还是内存，以我的理解，NSMutableDictionary 在 setValue:forKey:的时候确实会对 NSString \*key 进行 copy，但是这个 copy 不会产生新的内存分配（假定是 inmutable string ），只是把原有的 imutable string's retain count 加 1。上面说 NSMutableDictionary 的撑爆内存其实是指 NSMutableDictionary 持有的 NSString 把内存撑爆了。

这个理解有错误吗？请指正。

写 io 的话也想过，一旦 NSMutableDictionary 的数量级到了某个设定量就写文件，这样的话就还需要再次汇总结果了，可能不符合对方的预期。

这个问题来自蚂蚁金服的面试官。

@kera0a 对方明确说明了调用方数量确实会有很大，我猜测还是 NSString 作为 key 的内存占用量会很大。

也不排除因为他们的 app 在正常运行的时候其他需求上已经占用大量内存了，只是针对或者设计了这样一个问题来优化这个统计结果。

api 的数量会很大的，内存占用就不能小看了。
比如手淘 /支付宝之类的超大 app，底层做数据统计，整个 app 的 api 绝对是很恐怖的存在。
加上有的 api 是很长的，这个内存要求没问题的。

举个例子，你见过 6000 个会话的用户吗？
我在统计后台看到过。

简单写一下目前我能想的代码结构再讨论吧

```

void core_func(NSString *caller)
{
static NSMutableDictionary<NSString *, NSNumber *> *dict;
static dispatch_queue_t serialQueue;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
dict = [NSMutableDictionary new];
serialQueue = dispatch_queue_create("initializer.serial.queue", DISPATCH_QUEUE_SERIAL);
});

dispatch_async(serialQueue, ^{
if (dict[caller]) {
dict[caller] = @([dict[caller] unsignedIntegerValue] + 1);
} else {
dict[caller] = @1;
}

if (dict.count > 1000) {
NSString *url = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES).firstObject;
NSString *filename = [NSString stringWithFormat:@"stastics-data-%.3f", NSDate.date.timeIntervalSince1970];

url = [url stringByAppendingPathComponent:filename];

if ([dict writeToFile:url atomically:YES]) {
[dict removeAllObjects];
}
}
});
}

```

@ai277014717 以我的理解，只有给对象发送了 autorelease 消息的对象才会在 autoreleasepool 闭合的时候 release，其他对象还是一直存在的。ARC 下，上面的 url, filename 可以算是 autorelease 对象。
我印象中以前有看过关于 dispatch queue 在执行的时候外围其实已经包了一个 @autoreleasepool{ }，这样的话我觉得 autoreleased 对象并不能对内存构成威胁。

请指正。