建议不要转，Java 的趋势一定是比 iOS 的前景稳。

什么公司，哪个城市，我是 7 年 iOS，求推荐公司呀，诚心找

客观上的“框架不灵活”还是因为不合适，没有找到合适的框架。主观上的不灵活就是对别人的代码排外，不愿意接受事实而已，真香警告是早晚的

最近也在找工作：iOS 或者 Python 的，诚心就坑位或内推。简历： https://xingheng.github.io/resume/iOS-Resume/

楼主可能和老板那边的沟通有认知偏差：老板一般不在意新人具体是什么水平，从来都是能干活儿价钱划算就行，至于带人怎么带他才不在意。

@MagicBoy 杠一下：Java 什么时候都开始并入计算机基础了，我还真不会🙃

@crclz 学习了。我单独去查了一下“effective_spindle_count”的几篇文章，你说的 connection pool 大小是指的数据库层面的，不是 http/tcp connection 的。我觉得跟题主说的 API 层面上的 async 不太对等。

@xuanbg 你说得对，是我上面对“并发量”的描述不对，应该算 keepalive connection/request 比较准确。

@samlee123 抱歉，是我没有描述清楚。确定不是 hook msgsend，面试官明确说了被调用方知道是谁调用了自己，参见#16 的示例代码。

@hoyixi 那种存服务器的统计以前我还真写过，就是先写内存然后批量发到服务器，发送失败就临时写文件。但是我觉得面试官在这里应该不是问的一个设计上的问题，还是语言级的内存管理问题。

@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 的情况。

我的理解对吗？