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

请指正。

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

```

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 NSNumber 拆装箱过程中可能会产生局部变量，内存会在每次退出函数的时候就被释放了，我觉得不至于影响 NSMutableDictionary 所持有的内存。

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

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

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

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

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

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

@crclz 有理。那我们再往下(main thread)追溯，（我没有写过 c#服务端，从其他语言推断的），main thread 或者说函数入口一定是 sync，每一个从 port 过来的请求一定是在 c#服务端对应一个 working thread 的，高效管理是语言级的特性，但是 working thread 的数量一定是不会减少的，working thread 之间（对外）也没有依赖关系，所以并发量还是没有增大。

我上面的蛋炒饭(async)假定确实很 critical，全程只有一个 async task 的需求是非常少见的，async 在这种情况下应该是没有什么好处的，高效管理只是说损耗很小，但不是没有。

async 在设计层面上是成功的，也推荐使用。在 API 设计层面上我觉得只是相对提高了响应请求处理的单位时间，勉强上可以说是间接地提高了并发量。

请指正。

pydoc -k

Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 29 2018, 20:59:26)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin

>>> json.dumps({'y': 17318, 'info_total_periods': 12})
'{"y": 17318, "info_total_periods": 12}'
>>> json.dumps(cc)
'{"y": 17318, "info_total_periods": 12}'
>>>

没有重现

@xuanbg 这个🌰好。但是如果有客人(request)就点了一个蛋炒饭(async)，这样的话我觉得 sync 版的蛋烧饭会比 async 版的蛋炒饭更快，因为没有切换线程的损耗了。

关于楼上提到的并发量提高的问题我有些质疑，一个 request 在发起到完成之前，这个 working thread 应该是一直存在的，并不会因为 async 的使用导致 working thread dispose 或者 reuse 的情况。

我的理解对吗？

Talk is cheap, show me the code.

提到脚本居然不提 bash，那还是脚本嘛！

@baiyi

{"data":null}这种数据在前后端都有框架可以实现过滤；
现在主流的 iOS 数据序列化框架都可以区分{}和[]，你是不是被你们 iOS 客户端开发忽悠了

@Narcissu5 如果客户端要实现 code=9001 的时候立刻弹出登录页重新登录呢？这种逻辑绝对不止 1%

@helone 客户端有时候需要基于后台不同的 code 来实现不同的页面跳转等等特定需求

kon9chunkit 这是个什么破名字，私人汇总玩一下就可以了。高端玩法儿都是单独在 github 上创建 organization，然后托管，这样才上档次！

nginx 和 brew 这类命令可以直接在你的 terminal 里面用是因为你当前 shell session 的环境变量 PATH 里面包含了他们的所在路径，用`where brew`可以找到对应执行入口的路径。

vim $(where brew)，查看 brew 的执行入口文件是什么样的：
#!/bin/bash
set +o posix
....

从这里开始 shell 会解释执行这个 bash 脚本文件....你可以把自己写的脚本文件放到 PATH 之中的任一路径中，然后使用脚本文件名就可以被 shell 发现。

当然还有其他方法，比如 alias，shell/bash function，都可以满足你的这类需求。

百度搜索的结果也能用？头条也真够不挑的了，rua ji ！