ARC下的内存管理

1.ARC下单对象内存管理

  • 局部变量释放对象随之被释放
int main(int argc, const char * argv[]) {
   @autoreleasepool {
        Person *p = [[Person alloc] init];
    } // 执行到这一行局部变量p释放
    // 由于没有强指针指向对象, 所以对象也释放
    return 0;
}
  • 清空指针对象随之被释放
int main(int argc, const char * argv[]) {
   @autoreleasepool {
        Person *p = [[Person alloc] init];
        p = nil; // 执行到这一行, 由于没有强指针指向对象, 所以对象被释放
    }
    return 0;
}
  • 弱指针需要明确说明

    注意: 千万不要使用弱指针保存新创建的对象

int main(int argc, const char * argv[]) {
   @autoreleasepool {
        // p是弱指针, 对象会被立即释放
        __weak Person *p1 = [[Person alloc] init];
    }
    return 0;
}

2.ARC下多对象内存管理

  • ARC和MRC一样, 想拥有某个对象必须用强指针保存对象, 但是不需要在dealloc方法中release
@interface Person : NSObject

// MRC写法
//@property (nonatomic, retain) Dog *dog;

// ARC写法
@property (nonatomic, strong) Dog *dog;

@end

3.ARC下循环引用问题

  • ARC和MRC一样, 如果A拥有B, B也拥有A, 那么必须一方使用弱指针
@interface Person : NSObject

//@property (nonatomic, retain) Dog *dog;
@property (nonatomic, strong) Dog *dog;

@end

@interface Dog : NSObject

// 错误写法, 循环引用会导致内存泄露
//@property (nonatomic, strong) Person *owner;

// 正确写法, 当如果保存对象建议使用weak
//@property (nonatomic, assign) Person *owner;
@property (nonatomic, weak) Person *owner;
@end

4.ARC下@property参数

  • strong : 用于OC对象, 相当于MRC中的retain
  • weak : 用于OC对象, 相当于MRC中的assign
  • assign : 用于基本数据类型, 跟MRC中的assign一样
时间: 2025-01-20 01:16:11

ARC下的内存管理的相关文章

iOS: ARC & MRC下string内存管理策略探究

ARC & MRC下string内存管理策略探究 前两天跟同事争论一个关于NSString执行copy操作以后是否会发生变化,两个人整了半天,最后写代码验证了一下,发现原来NSString操作没我们想的那么简单,下面就让我们一起看看NSString和NSMutableString在MRC下执行retain,copy,mutableCopy,以及ARC下不同的修饰__weak, __strong修饰赋值究竟发生了什么. 一.验证代码如下: - (void)testStringAddress { i

objective-c启用ARC时的内存管理

PDF版下载:http://download.csdn.net/detail/cuibo1123/7443125      在objective-c中,内存的引用计数一直是一个让人比较头疼的问题.尤其是当引用计数涉及到arc.blocks等等的时候.似乎ARC的出现只是让我们解放了双手,由于底层实现依然依赖引用计数,所以开启ARC后,只有对引用计数机制更加了解,才能避免Cycle Retain.Crash等问题的出现. 但是由于使用ARC可以显著提高编码效率,所以建议尽量启用arc,本文内容也将

STL容器存储的内容动态分配情况下的内存管理

主要分两种情况:存储的内容是指针:存储的内容是实际对象. 看下面两段代码, typedef pair<VirObjTYPE, std::list<CheckID>*> VirObj_CheckID_pair; class LangChecker { public:     LangChecker();     ~LangChecker();         void Register(VirObjTYPE type, CheckID id); private:     std::m

iOS- 非ARC的项目内存管理细节详解(实战)

1.前言 接上文:iOS- 如何将非ARC的项目转换成ARC项目(实战) 2.内存管理时相关的配置 当我们把将非ARC的内存管理都管理好后,发现在做有些操作的时候内存还是在一直的缓慢增加 比如做一个最简单的随机数UITableView的显示与滑动,进行内存管理后,不应该出现内存增加的,但是一直滑动内存就一直缓慢的往上增加的情况. 这时候我们可以检查下看这里的属性是否打勾: 或者检测app一启动时控制台有没有立即输出下列这句话 如果勾上,上面三个选项,控制台就会出现下列几行输出 ARCTest(6

objective-c启用ARC时的内存管理 (循环引用)

PDF版下载:http://download.csdn.net/detail/cuibo1123/7443125          在Objective-C中,内存的引用计数一直是一个让人比较头疼的问题.尤其是当引用计数涉及到arc.blocks等等的时候.似乎ARC的出现只是让我们解放了双手,由于底层实现依然依赖引用计数,所以开启ARC后,只有对引用计数机制更加了解,才能避免Cycle Retain.Crash等问题的出现. 但是由于使用ARC可以显著提高编码效率,所以建议尽量启用arc,本文

ARC机制集合内存管理

// //  main.m //  13-ARC机制集合内存管理 // //  Created by apple on 14-3-21. //  Copyright (c) 2014年 apple. All rights reserved. // #import <Foundation/Foundation.h> #import "Person.h" //ARC机制,是否需要担心内存溢出呢 //谁告诉你不用的心得啊:道理就是下面的示 int main(int argc, c

glibc下的内存管理

在解码过程中我们也遇到了类似的问题,第一次解码的音频比较大60s,耗了3G的内存,reset之后内存并没有退还给操作系统,第二次即使解一个10s的音频 几周前我曾提到,我被项目组分配去做了一些探究linux下内存管理机制的活儿.因为我们的产品遇到了一些与之相关的“诡异”问题.这些问题以及相关情况可以概括如下: 先介绍一下相关的背景.由于我们是3D软件,所以用户经常会有“导入/导出”各种geometry的需求.而一个存储这些数据的文件,可能含有不止一个geometry,而且每个geometry中也

操作系统实验——工作集模型下的内存管理模拟

实验要求 现有若干进程,每个进程的页面访问顺序已经给出,并且这些进程交替地访问页面 设定一个工作集窗口Δ和内存页面数M 用一个数据结构维护每个进程的工作集,这个数据结构可以是数组或链表 根据进程访问页面的顺序,动态更新每个进程的工作集合和内存的空闲页面数 内存页面不足时,暂停某些进程.并在内存足够时,再将其唤醒 对给出的几个进程,利用工作集模型,进行内存的管理. 内存页面总数设为1000 工作集窗口初始可设为500左右,然后改变工作集窗口的大小,观察其对实验结果的影响 跟踪每个进程访问页面过程中

ARC 下处理内存暴涨的一个解决办法

有一种情况: for (int i = 0; i < 1000000000; i++) { NSString *s = @"ABC"; s = [s lowercaseString]; s = [s stringByAppendingString:@"ac"]; NSLog(@"%@", s); } 运行, 内存暴涨!!!!!! 这情况下, 给循环体里面的操作加一个 释放池 即可 for (int i = 0; i < 1000000