49、在上文5(1)中提到：当NSObject对象的retainCount减为0之后，就不要再去打印它的retainCount了，有可能导致crash。
为了验证这个说法，可以通过初始化一个对象并释放它，然后多次打印这个对象的retainCount来测试。
测试结果有很多种情况，取3种情况展示如下：
可以发现：再对象的retainCount减为0之后，再去打印它的retainCount，程序会随机在某个打印处crash。
对象被释放了还去访问它导致crash这个很好理解，但是为什么在[sth release]之后，这个NSObject的retainCount还是1呢？这是因为当retainCount为1的时候，再执行release的话对象就该被释放了，那么此时系统就会选择直接将对象释放掉（这样retainCount自然也就没有了），而不会多花费一次写内存的操作去修改它的retainCount为0。
所以在retainCount为1的时候执行了release之后，再去访问它的retainCount的时候，就只有两种结果：要么得到的retainCount为1，要么直接因为悬挂指针导致EXC_BAD_ACCESS。
另外，可以注意到，程序crash的位置是不固定的，由此也可以猜测：系统释放对象是异步执行的。
50、在MRC环境下，如果在一个有对象创建的循环外嵌套了@autoreleasepool块，当循环的次数多了，有可能会出现这些创建的对象直到@autoreleasepool块执行完才释放的情况，如下：
这时候如果将@autoreleasepool块移动到for循环的内部，每一次for循环都创建一个@autoreleasepool块，那么for循环内创建的对象就会被及时地释放了，如下图：
在ARC环境下则不会存在这个问题，不管使不使用@autoreleasepool块，for循环内创建的对象都会被及时地释放：
51、关于NSString的retainCount问题：
(1)、NSString的retainCount并不总是正确的，在不同的构造方法下，可能会得出不同的retainCount。
这是因为编译器有些情况下不会把NSString对象纳入内存管理的范畴，在这种情况下编译器会把NSString对象当成字符串常量来处理，就不会有retainCount了。甚至根据编译器的不同，完全相同的代码也有可能得出不同的retainCount。
这是完全视编译器而定的。
(2)、但是也可以测试一下，NSString几个常用的构造方法会怎样影响retainCount。使用以下代码来测试：
输出结果如下：
(3)、可以看到：
①、使用直接赋值、init方法或者initWithString:方法，retainCount都是-1，说明这种情况下NSString对象就被当做字符串常量来处理了。同时可以注意到直接赋值和使用initWithString:方法得到的NSString对象的地址是相同的，进一步说明它们被当做同一个字符串常量处理了；
②、比较诡异的是initWithFormat:和stringWithFormat:这两种构造方法，在使用汉字或者使用英文且字符较长的时候，编译器会将它当做正常对象来处理，会有retainCount，当英文字符较短时，编译器会将它当做字符串常量来处理；
(4)、在这里只是做一个测试，其实关注retainCount是不符合内存管理4个规则的管理思想的，进行内存管理的时候关注重点应当是持有与释放对象，而不是去关注有多少指针持有了这个对象（retainCount）。
