iOC中block下的__block、__Strong、__weak

iOC中block下的__block、__Strong、__weak,第1张

两个对象相互持有,这样就会造成循环引用,如下图所示

图中,对象A持有对象B,对象B持有对象A,相互持有,最终导致两个对象都不能释放。

最普通的情况,由于block会对block中的对象进行持有 *** 作, 就相当于持有了其中的对象 ,而如果此时block中的对象又持有了该block,则会造成循环引用。如下:

调用以上三句均会造成循环引用,因为不管是通过 selfblockString 还是 _blockString ,或是函数调用 [self doSomething] , 因为只要 block中用到了对象的属性或者函数,block就会持有该对象而不是该对象中的某个属性或者函数。

当有someObj持有self对象,此时的关系图如下。

当someObj对象release self对象时,self和myblock相互引用,retainCount都为1,造成循环引用

解决:

使用 __weak 修饰self,使其在block中不被持有,打破循环引用。开始状态如下

当someObj对象释放self对象时,Self的retainCount为0,走dealloc,释放myBlock对象,使其retainCount也为0。

其实以上循环引用的情况很容易发现,因为此时Xcode就会报警告。而发生在多个对象间的时候,Xcode就检测不出来了,这往往就容易被忽略。

解决方法:

将objA对象weak,使其不在block中被持有

注:以上使用 __weak 打破循环的方法只在ARC下才有效,在MRC下应该使用 __block

或者,在block执行完后,将block置nil,这样也可以打破循环引用

这样做的缺点是,block只会执行一次,因为block被置nil了,要再次使用的话,需要重新赋值。

在开发工程中,发现一些同学并没有完全理解循环引用,以为只要有block的地方就会要用__weak来修饰对象,这样完全没有必要,以下几种block是不会造成循环引用的。

大部分GCD方法

因为self并没有对GCD的block进行持有,没有形成循环引用。目前我还没碰到使用GCD导致循环引用的场景,如果某种场景self对GCD的block进行了持有,则才有可能造成循环引用。

block并不是属性值,而是临时变量

这里因为block只是一个临时变量,self并没有对其持有,所以没有造成循环引用

看下面例子,有这种情况,如果不只是ClassA持有了myBlock,ClassB也持有了myBlock。

当ClassA被someObj对象释放后

此时,ClassA对象已经被释放,而myBlock还是被ClassB持有,没有释放;如果myBlock这个时被调度,而此时ClassA已经被释放,此时访问的ClassA将是一个nil对象(使用 __weak 修饰,对象释放时会置为nil),而引发错误。

另一个常见错误使用是,开发者担心循环引用错误(如上所述不会出现循环引用的情况),使用 __weak 。比如

此时导致doSomething直接无法执行,因为 block作为参数传给dispatch_async时,系统会将block拷贝到堆上,而且block会持有block中用到的对象 ,因为dispatch_async并不知道block中对象会在什么时候被释放,为了确保系统调度执行block中的任务时其对象没有被意外释放掉, dispatch_async必须自己retain一次对象(即self),任务完成后再release对象(即self) 。但这里使用 __weak ,使dispatch_async没有增加self的引用计数,这使得在系统在调度执行block之前,self可能已被销毁,但系统并不知道这个情况,导致block执行时访问已经被释放的self,而达不到预期的结果。

理解这点很重要,这是许多使用 __weak,__stong 的由来,实际的过程原理与block实现有关,下文会补充,这里先记住这点。

注:如果是在MRC模式下,使用 __block 修饰self,则此时block访问被释放的self,则会导致crash。 如下:

运行结果

解决方法:

对于这种场景,就不应该使用 __weak 来修饰对象,让dispatch_after对self进行持有,保证block执行时self还未被释放。

还有一种场景,在block执行开始时self对象还未被释放,而执行过程中,self被释放了,此时访问self时,就会发生错误。

对于这种场景,应该在block中对 对象使用 __strong 修饰,使得在block期间对 对象持有,block执行结束后,解除其持有。这也就是为什么许多使用block的地方内外要

注:此方法只能保证在block执行期间对象不被释放,如果对象在block执行执行之前已经被释放了,该方法也无效。

讲到这里不得不提及一下 __block 。承接前面的例子,均是在block中使用其他对象的方法。实际应用中会有在block使用变量,或其他对象属性的情况。如下:

亦或是

无论是在block中修改外部变量、或是对其他熟悉的 *** 作。因为block在其他线程中执行,取值时是进行copy *** 作,如果是有self等引用则不会有问题,如果是外部变量或临时声明的对象,在block做处理 *** 作时则要考虑,是否希望改变原来的值。这里的__block起到了原来c语言中&取地址,传递地址的作用。

这里的作用机理和block的机理有关,block本身的核心逻辑是C中的匿名方法,因为C语言中方法是可以作为属性来传递的,OC中将block需要使用的方法快作为匿名方法的熟悉,封装在一个结构体中。而这句__block则是将对于需要传递内存的属性/对象一同封装在这个结构体中。

不过我个人觉得,这种临时变量需要在block中进行处理,然后希望同时影响外部的需求。我认为在业务需求上是很少用到的,大家想避免还是很容易。

1要注意block本身持有情况,及block内部的持有情况,尤其是类似“ block myBlock”等已经在类内部全局声明持有的block

2block本身并不是属性值,而是临时变量,故不要一味的在weak中使用weak

3在block外部声明的临时变量,需要在block内部继续使用时,要用__strong声明,来防止在进入block前,已经被释放掉了。

4如果有临时变量/对象需要放到block中处理,且希望是Strong传递而非Copy传递则用 __block 修饰

小声bb:讲了这么多,其实很简单,遇到block,先看block是否全局引用了,如果全局引用了,则其内部的self等必然要weak处理。二要看内部是否使用了临时变量/对象的方法,如果使用了则要考虑是否需要使用strong防止对象过程释放。__block就是给临时变量,修改隐性的copy为strong。

本篇中许多内容引用自

>

__attribute__是gcc专有的,用来说明函数的熟性

weak 和 alias 分别是两个属性。weak 使得 main 这个符号在目标文件中作为 weak symbol 而不是 global symbol。用 nm 命令查看编译 dummyc 生成的目标文件可用看到 main 是一个 weak symbol,它前面的标记是 W。

而 alias 则使main 是 alt_main 的一个别名,alt_main 和 main 必须在同一个编译单元中定义,否则会编译出错。

很早Java API就添加了弱引用(WeakReference)和软引用(SoftReference),引用类在垃圾回收工作的过程中有重要作用。我们都知道垃圾回收器会回收符合回收条件的对象的内存,但并不是所有的程序员都知道回收条件取决于指向该对象的引用类型。

这正是Java中弱引用和软引用的主要区别。如果一个对象只有弱引用指向它,垃圾回收器会立即回收该对象,这是一种急切回收方式。相对的,如果有软引用指向这些对象,则只有在JVM需要内存时才回收这些对象。弱引用和软引用的特殊行为使得它们在某些情况下非常有用。例如:软引用可以很好的用来实现缓存,当JVM需要内存时,垃圾回收器就会回收这些只有被软引用指向的对象。而弱引用非常适合存储元数据,例如:存储ClassLoader引用。

如果有类被加载,那么也没有指向ClassLoader的引用。一旦上一次的强引用被去除,只有弱引用的ClassLoader就会被回收。

Java中弱引用VS软引用

Java中有如下四种类型的引用:

强引用(Strong Reference)

弱引用(WeakReference)

软引用(SoftReference)

虚引用(PhantomReference)

强引用是我们在编程过程中使用的最简单的引用,如代码String s=”abc”中变量s就是字符串对象”abc”的一个强引用。任何被强引用指向的对象都不能被垃圾回收器回收,这些对象都是在程序中需要的。弱引用使用javalangrefWeakReference class 类来表示,你可以使用如下代码创建弱引用:

代码如下:

Counter counter = new Counter(); // strong reference - line 1

WeakReference<Counter> weakCounter = new WeakReference<Counter>(counter);

//weak reference

counter = null; // now Counter object is eligible for garbage collection

现在只要你给强引用对象counter赋空值null,该对象就可以被垃圾回收器回收。因为该对象此时不再含有其他强引用,即使指向该对象的弱引用weakCounter也无法阻止垃圾回收器对该对象的回收。相反的,如果该对象含有软引用,Counter对象不会立即被回收,除非JVM需要内存。Java中的软引用使用javalangrefSoftReference类来表示,你可以使用如下代码创建软引用:

代码如下:

Counter prime = new Counter(); // prime holds a strong reference _ line 2

SoftReference soft = new SoftReference(prime) ; //soft reference variable has

SoftReference to Counter Object created at line 2

prime = null; // now Counter object is eligible for garbage collection but only be

collected when JVM absolutely needs memory

强引用置空之后,代码的第二行为对象Counter创建了一个软引用,该引用同样不能阻止垃圾回收器回收对象,但是可以延迟回收,与弱引用中急切回收对象不同。鉴于软引用和弱引用的这一区别,软引用更适用于缓存机制,而弱引用更适用于存贮元数据。另一个使用弱引用的例子是WeakHashMap,它是除HashMap和TreeMap之外,Map接口的另一种实现。

WeakHashMap有一个特点:map中的键值(keys)都被封装成弱引用,也就是说一旦强引用被删除,WeakHashMap内部的弱引用就无法阻止该对象被垃圾回收器回收。

虚引用是javalangref package包中第三种可用的引用,使javalangrefPhantomReference类来表示。拥有虚引用的对象可以在任何时候被垃圾回收器回收。和弱引用和软引用相似,你可以通过如下代码创建虚引用:

代码如下:

DigitalCounter digit = new DigitalCounter(); // digit reference variable has strong

reference _ line 3

PhantomReference phantom = new PhantomReference(digit); // phantom reference to object created at line 3

digit = null;

一旦移除强引用,第三行的DigitalCounter对象可以在任何时候被垃圾回收器回收。因为只有一个虚引用指向该对象,而虚引用无法阻止垃圾回收器回收对象。

除了了解弱引用、软引用、虚引用和WeakHashMap,还需要了解ReferenceQueue。在创建任何弱引用、软引用和虚引用的过程中你可以通过如下代码提供引用队列ReferenceQueue:

代码如下:

ReferenceQueue refQueue = new ReferenceQueue(); //reference will be stored in this queue for cleanup

DigitalCounter digit = new DigitalCounter();

PhantomReference<DigitalCounter> phantom = new

PhantomReference<DigitalCounter>(digit, refQueue);

引用实例被添加在引用队列中,你可以再任何时候通过查询引用队列回收对象。一个对象的生命周期可以通过下图进行描述:

在新窗口打开

这就是Java中弱引用和软引用的区别。我们还学到了一些基本的引用类:弱引用、软引用、虚引用以及WeakHashMap和WeakHashMap。总之,合理的使用引用可以帮助垃圾回收器更好的管理Java内存。

以上就是关于iOC中block下的__block、__Strong、__weak全部的内容,包括:iOC中block下的__block、__Strong、__weak、iOS 用assign修饰对象会怎么样、int main (void) __attribute__ ((weak, alias ("alt_main")));嘛意思等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/9829262.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-02
下一篇 2023-05-02

发表评论

登录后才能评论

评论列表(0条)

保存