weak-references

How to force full garbage collection in .NET 4.x?

由 大兔子大兔子 提交于 2019-11-30 23:42:59
问题 I've a problem with WeakReferences in .NET 4.x, I was running tests to make sure some objects were not referenced anymore (using WeakReferences) and I noticed the behavior is not consistent across framework versions: using System; using System.Text; using NUnit.Framework; [TestFixture] public class WeakReferenceTests { [Test] public void TestWeakReferenceIsDisposed() { WeakReference weakRef = new WeakReference(new StringBuilder("Hello")); GC.Collect(); GC.WaitForPendingFinalizers(); GC

strange WeakReference behavior on Mono

由 。_饼干妹妹 提交于 2019-11-30 22:26:46
问题 Testing code that uses WeakReference failed for me using Mono 2.11.3 (SGen) as well as the stable 2.10.8 version. In a simple code like this object obj = new object(); WeakReference wr = new WeakReference(obj); Assert.IsTrue(wr.IsAlive); obj = null; GC.Collect(); Assert.IsFalse(wr.IsAlive); the second assert will fail. Adding GC.WaitForPendingFinalizers doesn't help. Is this a bug in Mono or in my head? Thanks 回答1: It is not a bug, but an implementation detail where the Mono GC behaves

ArrayList<WeakReference<Runnable>> - How to tidy up best?

由 ε祈祈猫儿з 提交于 2019-11-30 20:22:02
A quick question in between: I have a simple WeakRunnableList. Is this way ok to clean it up (removing dead references), or is there a more elegant and faster solution. Full source for my WeakRunnableList: public class WeakRunnableList { private ArrayList<WeakReference<Runnable>> _items = new ArrayList<WeakReference<Runnable>>(); public void Add(Runnable r) { _items.add(new WeakReference<Runnable>(r)); } public void Execute() { ArrayList<WeakReference<Runnable>> remove = new ArrayList<WeakReference<Runnable>>(); for (WeakReference<Runnable> item : _items) { Runnable tempCheck = item.get(); if

EXC_BAD_ACCESS on objc_setAssociatedObject with -weak_library /usr/lib/libSystem.B.dylib linker flags

由 倾然丶 夕夏残阳落幕 提交于 2019-11-30 19:53:14
I have a EXC_BAD_ACCESS when I call objc_setAssociatedObject with the linker flags : -weak_library /usr/lib/libSystem.B.dylib linker flags. I absolutely need the linker flag because of this , do somebody know a workaround? (I also have a crash on dispatch_async but I can work around that... Also, I'm building a iOS 4 only feature on my app that is iOS 3 compatible) EDIT: With more research, I found this and this question but no more answer... The problem is simply a bug in the iOS Simulator. The codes works fine on the device. I've filled a radar on Apple's bug reporter (radar://9470793) EDIT:

How does a value in an entry in the WeakHashMap gets garbage collected when the actual object is garbage collected?

由 别说谁变了你拦得住时间么 提交于 2019-11-30 19:44:29
问题 First of all I would like to clarify my understanding of the WeakReference as the following question depends on the same. static void test() { Person p = new Person(); WeakReference<Person> person = new WeakReference<>(p); p = null; System.gc(); System.out.println(person.get()); System.out.println(person); } static class Person { String name; } static class PersonMetadata { String someData; public PersonMetadata(String met) { someData = met; } } The output of the above code is null java.lang

Weak Self in Blocks

由 时光怂恿深爱的人放手 提交于 2019-11-30 19:12:56
问题 Do I need to check if weak self is nil in blocks? I create weakSelf pointer like: __weak typeof(self) weakSelf = self; and in the beginning of the blocks I do if(!weakSelf){return;} is this unnecessary? or does it depend on whether I coded the rest correctly so that when the self dies, others die too? 回答1: That check is unnecessary, and is giving you a false sense of security. Here's the problem: __weak typeof(self) weakSelf = self; dispatch_async(dispatch_get_main_queue(), ^{ if (!weakSelf)

When does a weak reference get updated to nil in Objective-C? [duplicate]

由 浪尽此生 提交于 2019-11-30 17:45:50
问题 This question already has answers here : Why isn’t my weak reference cleared right after the strong ones are gone? (4 answers) Closed 6 years ago . Consider the following two cases: // case 1 NSObject *strongOne = [[NSObject alloc] init]; NSObject * __weak weakOne = strongOne; if (weakOne) { NSLog(@"weakOne is not nil."); } else { NSLog(@"weakOne is nil."); } strongOne = nil; if (weakOne) { NSLog(@"weakOne is not nil."); } else { NSLog(@"weakOne is nil."); } Outputs this: weakOne is not nil.

Safely iterating over WeakKeyDictionary and WeakValueDictionary

由 瘦欲@ 提交于 2019-11-30 15:02:04
问题 The documentation of Python 3.2 's weakref module's WeakKeyDictionary and WeakValueDictionary have a note on iterating over these containers: Note: Caution: Because a WeakKeyDictionary is built on top of a Python dictionary, it must not change size when iterating over it. This can be difficult to ensure for a WeakKeyDictionary because actions performed by the program during iteration may cause items in the dictionary to vanish “by magic” (as a side effect of garbage collection). That seems

ThreadLocal Resource Leak and WeakReference

由 两盒软妹~` 提交于 2019-11-30 13:44:30
问题 My limited understanding of ThreadLocal is that it has resource leak issues. I gather this problem can be remedied through proper use of WeakReferences with ThreadLocal (although I may have misunderstood this point.) I would simply like a pattern or example for correctly using ThreadLocal with WeakReference, if one exists. For instance, in this code snippet where would the WeakReference be introduced? static class DateTimeFormatter { private static final ThreadLocal<SimpleDateFormat> DATE

Safely iterating over WeakKeyDictionary and WeakValueDictionary

由 给你一囗甜甜゛ 提交于 2019-11-30 13:43:09
The documentation of Python 3.2 's weakref module's WeakKeyDictionary and WeakValueDictionary have a note on iterating over these containers: Note: Caution: Because a WeakKeyDictionary is built on top of a Python dictionary, it must not change size when iterating over it. This can be difficult to ensure for a WeakKeyDictionary because actions performed by the program during iteration may cause items in the dictionary to vanish “by magic” (as a side effect of garbage collection). That seems rather dire as a specification of these container's behavior. Especially when running code that uses
订阅 weak-references