NSString 在 OC 的内存管理策略中是一个特殊的存在，因为其在编译和运行中做了一些优化处理，不同于普通对象的存在，看看下面代码打印情况（此代码测试环境为MRC，可以在ARC工程下，设置当前测试代码文件为手动内存管理，找到路径Build Phases---->Compile Sources---->XXX.m，将XXX.m的Compiler Flags设置为"-fno-objc-arc".）：
//宏定义
#define XWLog(_var) ({ NSString *name = @#_var; NSLog(@"变量名=%@，类型=%@， 地址=%p，值=%@，引用计数=%d", name, [_var class], _var, _var, (int)[_var retainCount]); })
//测试代码
NSString *a = @"string";
NSString *b = [[NSString alloc]init];
NSString *c = [[NSString alloc]initWithString:@"string"];
NSString *d = [[NSString alloc]initWithFormat:@"string"];
NSString *e = [NSString stringWithFormat:@"string"];
NSString *f = [NSString stringWithFormat:@"123456789"];
NSString *g = [NSString stringWithFormat:@"1234567890"];
XWLog(a); XWLog(b); XWLog(c); XWLog(d); XWLog(e); XWLog(f); XWLog(g);
//打印结果
变量名=a，类型=__NSCFConstantString， 地址=0x1015f3120，值=string，引用计数=-1
变量名=b，类型=__NSCFConstantString， 地址=0x1019808d0，值=，引用计数=-1
变量名=c，类型=__NSCFConstantString， 地址=0x1015f3120，值=string，引用计数=-1
变量名=d，类型=NSTaggedPointerString， 地址=0xa00676e697274736，值=string，引用计数=-1
变量名=e，类型=NSTaggedPointerString， 地址=0xa00676e697274736，值=string，引用计数=-1
变量名=f，类型=NSTaggedPointerString， 地址=0xa1ea1f72bb30ab19，值=123456789，引用计数=-1
变量名=g，类型=__NSCFString， 地址=0x60800002b580，值=1234567890，引用计数=1
从打印结果看出，变量 b 到 f 的引用计数为-1，若是无符号格式输出，应该是一个很大的数字，与我们理解的对象初始化后引用计数为 1 所不同，不同的创建方式，字符串的类型不同，引用计数也有区别，创建的字符串有三种类型：
__NSCFConstantString
__NSCFString
NSTaggedPointerString
造成这种情况是由于 OC 对 NSString 的内存优化产生的。
- __NSCFConstantString
从字面就可以看出，这是一个常量字符串，该类型的字符串是以字面量创建的，是在编译期创建的，保存在常量区。通过 a 与 c 的打印结果看出，当创建的字符串变量值在常量区存在时，变量会指向那个字符串，这是编译期做的优化，c 指向同一字符串 @"string"，地址与a相同。
文字常量区存放常量字符串，程序结束后由系统释放，也就是说指向常量表的指针不受引用计数管理。所以对于
NSCFConstantString类型的变量，OC 的内存管理策略对其无效。
__NSCFString
表示这是一个对象类型的字符串，在运行时创建，存储在堆区，服从OC 的对象内存管理策略。该类型的字符串由Format创建，无论是实例方法还是类方法且其长度不能太小（内容若包含中文字符，不论长度大小，都是NSCFString），否则创建的是NSTaggedPointerString类型，例如上例的变量 f 与 g。NSTaggedPointerString
对于64位程序，为了节省内存和提高运行速度，苹果引入了 Tagged Point 技术。NSTaggedPointerString是对NSCFString优化后的存在，在运行时创建时对字符串的内容和长度做出判断，若字符串内容是由ASCII字符构成且长度较小（大概十个字符以内），这时候创建的字符串就是NSTaggedPointerString类型，字符串直接存储在指针里，引用计数同样为-1，不适用对象的内存管理策略。
Tagged Pointer指针的值不再是地址了，而是真正的值。所以，实际上它不再是一个对象了，它只是一个披着对象皮的普通变量而已。所以，它的内存并不存储在堆中，OC 对象的内存管理方式对其无效。
现在，我们在看看这道题：
在MRC下，会不会造成内存泄漏？会不会奔溃？
NSString *str = [[NSString alloc] initWithString:@"ABC"];
str = @"123";
[str release];
NSLog(@"%@".str);
一目了然，str指向字符串常量，对象的内存管理方式对其无效，程序结束时，系统才会销毁常量区的值。所以不会造成内存泄漏更不会奔溃。
接下来我们再看看NSArray的平时注意不到的问题：
NSArray *a1 = @[@"1",@"2"];
NSArray *a2 = [[NSArray alloc]init];
NSArray *a3 = [[NSArray alloc]initWithObjects:@"1", nil];
NSArray *a4 = [[NSArray alloc]initWithArray:@[@"a",@"b"]];
NSArray *a5 = [NSArray arrayWithObjects:@"m",@"n", nil];
NSArray *a6 = [[NSArray alloc]init];
NSArray *a7 = @[];
XWLog(a1); XWLog(a2); XWLog(a3); XWLog(a4); XWLog(a5); XWLog(a6);XWLog(a7);
打印结果：
变量名=a1，类型=__NSArrayI， 地址=0x608000029400，值=(1,2)，引用计数=1
变量名=a2，类型=__NSArray0， 地址=0x618000012490，值=()，引用计数=-1
变量名=a3，类型=__NSSingleObjectArrayI， 地址=0x608000012890，值=(1)，引用计数=1
变量名=a4，类型=__NSArrayI， 地址=0x608000029440，值=(a,b)，引用计数=1
变量名=a5，类型=__NSArrayI， 地址=0x608000029460，值=(m,n)，引用计数=1
变量名=a6，类型=__NSArray0， 地址=0x618000012490，值=()，引用计数=-1
变量名=a7，类型=__NSArray0， 地址=0x618000012490，值=()，引用计数=-1
从结果看出，只有a2 a6 a7这三个的引用计数为-1，其他变量的引用计数为1，显示正常。我们仔细发现，这三个的地址相同，这就是说三个变量指向了同一块内存，说明a2 a6 a7三个创建方式创建的空实例是一个特殊值的存在，其应该存储在常量静态区。我们可以猜测，OC为了优化内存，在常量静态区创建一个空值的特殊存在，应该是静态常量对象，无论什么方式创建的空实例，其都指向静态区这个空值的。
不仅是NSArray，Foundation中如NSString, NSDictionary, NSSet等区分可变和不可变版本的类，空实例都是静态对象（NSString的空实例对象是常量区的@""）,对象的内存管理策略对其无效。
