https://kotlinlang.org logo
Join Slack
Powered by
According to many difference sources on the web `b...
# announcements
d
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.
m
It’s not a language issue, so it hasn’t changed.
➕ 1
👍 2
The problem lies in loading 
by lazy
some value which depends on a mutable state
In this case the 
view
d
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)
and I'm concerned of memory leaks
Copy code
private class SynchronizedLazyImpl<out T>(initializer: () -> T, lock: Any? = null) : Lazy<T>, Serializable {
    private var initializer: (() -> 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)
}
it does
Copy code
initializer = null
after using it
before that it holds an indirect reference to the class containing the 
by lazy
.
m
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
e
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
m
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
@Egor Trutenko I don’t know what you mean
d
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?
m
Not necessarily, Fragment instances can be detached and re-attached, effectively recreating their view, without being destroyed
The joys of the fragment lifecycle 🙂
e
I mean, why even try to initialize views via lazy instances? 
lazy
is not meant for that, 
lateinit
is
d
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
m
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.
d
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
m
Like I said, memory leaks are an issue if 
lazy
is loading a value which depends on a mutable state
d
and I just want to know if thee by lazy can cause memory leaks
mutable state has nothing to do with memory leaks
m
It has everything to do with memory leaks…
d
a memory leak is caused by something holding a reference to an object that is supposed to have been garbage collected
a
even if you use a 
lateinit var
, or a nullable 
var
you can recreate the same memory leak from the tweet
e
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.
m
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.
d
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?
m
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.,
d
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
m
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 & garbage collected then the lazy instance will also get released, lambda & value.
d
perfect, then it works as I expected and means by lazy doesn't leak anything.
m
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.
d
?
m
In your second case, with the fragment which hasn’t loaded the value yet
I think it will access the property again through the getter, so it should “work”, but it would still be terrible code
d
Copy code
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?
the lambda initializer has a reference to my fragment in this case.
Martin Devillers do you mind telling me why you call that code terrible?
r
Please don’t blame your ignorance of how a feature works on the feature.
m
I mean a code that would rely on a 
lazy
property not having been already initialized when calling it would be terrible
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.
156 Views
Open in Slack
PreviousNext
Powered by