According to many difference sources on the web `by lazy` ca

Question

According to many difference sources on the web `by lazy` can cause memory leaks Notable one <https twitter com chrisbanes status 897075635142754305> Is this an old issue that has been solved in recent versions of kotlin or is it still a gotcha that the developer has to take care of If still a gotcha any suggestion on how to handle values that might not be initialized As far as I understand I can t access the delegate directly

Martin Devillers · Answer

It s not a language issue so it hasn t changed

Martin Devillers · Answer

The problem lies in loading `by lazy` some value which depends on a mutable state

Martin Devillers · Answer

In this case the `view`

Daniele Segato · Answer

I m not using it for views I use it on stuff that doesn t change during the lifespan of the object but is not available when the object is constructed aka = activity or fragment in Android

Daniele Segato · Answer

and I m concerned of memory leaks

Daniele Segato · Answer

``` private class SynchronizedLazyImpl lt out T gt initializer gt T lock Any = null Lazy lt T gt Serializable private var initializer gt T = initializer Volatile private var value Any = UNINITIALIZED VALUE final field is required to enable safe publication of constructed instance private val lock = lock this override val value T get val v1 = value if v1 == UNINITIALIZED VALUE Suppress UNCHECKED CAST return v1 as T return synchronized lock val v2 = value if v2 == UNINITIALIZED VALUE Suppress UNCHECKED CAST v2 as T else val typedValue = initializer value = typedValue initializer = null typedValue override fun isInitialized Boolean = value == UNINITIALIZED VALUE override fun toString String = if isInitialized value toString else Lazy value not initialized yet private fun writeReplace Any = InitializedLazyImpl value ```

Daniele Segato · Answer

it does ``` initializer = null ``` after using it

Daniele Segato · Answer

before that it holds an indirect reference to the class containing the `by lazy`

Daniele Segato · Answer

This guy say Kotlin hold the reference <https stackoverflow com questions 51718733 why kotlin by lazy can cause memory leak in android>

Martin Devillers · Answer

The problem presented in the Tweet that you shared isn t about the initializer leaking anything it s about the loaded value which is leaking a whole view hierarchy which is obsolete

Egor Trutenko · Answer

The root of the problem is that people actually mistake lazy initialization to late initialization which might seem the same thing but apparently not in Kotlin

Martin Devillers · Answer

Simply put Fragment is created Field is accessed lazily loaded from the view Fragment is re created therefore an entirely new view is created When accessing the field it still uses the value that it had loaded from the previous view rather than re loading it from the previous one

Martin Devillers · Answer

< Egor Trutenko> I don t know what you mean

Daniele Segato · Answer

Martin if the view is recreated on the same fragment after the by lazy has already produced a value I completely agree it shouldn t use the new view but if the fragment is re created shouldn t the by lazy be an entirely new object

Martin Devillers · Answer

Not necessarily Fragment instances can be detached and re attached effectively recreating their view without being destroyed

Martin Devillers · Answer

The joys of the fragment lifecycle slightly smiling face

Egor Trutenko · Answer

I mean why even try to initialize views via lazy instances `lazy` is not meant for that `lateinit` is

Daniele Segato · Answer

well yeah of course in that case I wouldn t use by lazy unless it is not strictly related to stuff that doesn t change on the same fragment

Martin Devillers · Answer

Both tools are valid and have different consequences Using `lateinit` usually means that you re loading all your view references at creation which is something which was initially discouraged because of the overhead although I d argue that it s generally insignificant on modern devices Using `lazy` means that your view references are loaded only when they re needed

Daniele Segato · Answer

I m not using by lazy for views I use the kotlin view binding extension That s just the example written by Chris Banes my question was about memory leaks

Martin Devillers · Answer

Like I said memory leaks are an issue if `lazy` is loading a value which depends on a mutable state

Daniele Segato · Answer

and I just want to know if thee by lazy can cause memory leaks

Daniele Segato · Answer

mutable state has nothing to do with memory leaks

Martin Devillers · Answer

It has everything to do with memory leaks

Daniele Segato · Answer

a memory leak is caused by something holding a reference to an object that is supposed to have been garbage collected

arekolek · Answer

even if you use a `lateinit var` or a nullable `var` you can recreate the same memory leak from the tweet

Egor Trutenko · Answer

Yes but only if you try hard to More complicated instruments like `lazy` are discouraged to apply to poorly architectured frameworks Android because of such unexpected behavior and leaks

Martin Devillers · Answer

I m well aware of what a memory leak is And the issue with memory leaks is because the state has mutated therefore some instances should be collected

Daniele Segato · Answer

say Activity X instance A and B a `by lazy` in A is never initialized not used The initialization lambda hold a reference to instance A When A gets destroyed and B created I expect the by lazy to go away and not keep A alive B has it s own by lazy Is that true

Martin Devillers · Answer

Explained differently instances loaded by `lazy` will have the same memory lifecycle as the instance in which they were created Ask yourself whether that s what your want or not If the block of `lazy` depends on some state of the outer instance which is going to mutate then the answer is no

Daniele Segato · Answer

then there s the other case Fragment Y same thing but it survive between A and B In this case an uninitialized `by lazy` should only have a reference to the fragment and thus shouldn t leak activity A when it is initialized it MIGHT leak activity A depending on what value has been initialized to This is how I expect it to work

Martin Devillers · Answer

I m not sure I understand your exemple but if you have a `lazy` field in a component like an `activity` then if that activity gets destroyed amp garbage collected then the lazy instance will also get released lambda amp value

Daniele Segato · Answer

perfect then it works as I expected and means by lazy doesn t leak anything

Martin Devillers · Answer

You re describing an edge case which really shouldn t be relied on It depends on how lambdas capture their class properties which I m not sure of

Martin Devillers · Answer

In your second case with the fragment which hasn t loaded the value yet

Martin Devillers · Answer

I think it will access the property again through the getter so it should work but it would still be terrible code

Daniele Segato · Answer

``` private val viewModel MyViewModel by lazy ViewModelProviders of requireActivity get MyViewModel class java ``` the initialization need the activity `requireActivity ` to initialize but the `MyViewModel` itself has no reference that leak the activity or the fragment how is this terrible code

Daniele Segato · Answer

the lambda initializer has a reference to my fragment in this case

Daniele Segato · Answer

Martin Devillers do you mind telling me why you call that code terrible

ribesg · Answer

Please don t blame your ignorance of how a feature works on the feature

Martin Devillers · Answer

I mean a code that would rely on a `lazy` property not having been already initialized when calling it would be terrible

Martin Devillers · Answer

Regarding your example if your view model can only be used by the activity then you re fine If it s likely to be used by a different activity then you ll likely have a problem