Let’s start with a couple of small questions

I have a class of my own:

class Person(var name: String) {
    fun introduce(a): String = "My name is $name"
}
Copy the code

Question 1: Putting an instantiated object into a List does the process create a new object, or does it simply create a memory space pointing to the instantiated object?

In short:

If I put the Person in the List and change the name outside, will it change the name inside the List?

The answer:

Will!!!!!

fun main(args: Array<String>) {
    val list = arrayListOf<Person>()
    val person = Person(Daniel Wu)
    list.add(person)
    println(person.toString())
    println(list[0].toString())
    println(person.name)
    println(list[0].name)

    person.name = "Eddie Peng"

    println(person.name)
    println(list[0].name)

    list[0].name = "Li Yifeng"

    println(person.name)
    println(list[0].name)
}
Copy the code

Output result:

Person@5594a1b5 Person@5594a1b5 Yan Wu Yan Wu Yuyan Peng Yifeng Li Yifeng Peng Yifeng LiCopy the code

You can see that the HashCode we printed is exactly the same, and that the objects declared outside are synchronized with the ones in the List!

This is very reasonable, both in terms of memory model and design. Moreover, this is very consistent with real life. When you queue up in real life, you also queue up by yourself, instead of calling a ghost and letting him queue up instead of you.

Question two: will putListObject release (assigned tonull ),ListWill the objects in the book change?

fun main(args: Array<String>) {
    vallist = arrayListOf<Person? > ()var person: Person? = Person(Daniel Wu)
    list.add(person)
    println(person.toString())
    println(list[0].toString()) println(person? .name) println(list[0]? .name) person =null

    println(person)
    println(list[0])}Copy the code

Output result:

Person@5594a1b5 Person@5594a1b5 Daniel Wu Null Person@5594a1b5Copy the code

As you can see, releasing an external object does not free the object in the List. This makes sense because assignment does not change the original object. Instead, it refers to another object (regardless of the underlying data type).

As shown in the picture :(square represents memory, dotted line represents empty)

Consider: What problems does this cause

If you know how GC works on the JVM. You may have heard of an algorithm called reachability, where objects that are unreachable are recycled in the next GC

Reachable means that there is a reference to a variable in memory, which is the arrow with the thin black line in my image

In short: if you have access to something, it’s reachable, and if you don’t, it’s unreachable

When we put an object into a List, the List holds a reference to the object (the List leads to an arrow pointing to the object).

As shown in the picture :(square represents memory, dotted line represents empty)

Visible, whenpersonTo be an assignmentnull.Person@5594a1b5This chunk of memory is stillCan be up toWe can still use itListVisit him so he won’t beJVMrecycling

If we put an instantiation object of an Activity into a List, we may not be able to free up memory for the Activity, breaking the life cycle

In general, we should avoid referencing activities, services, and other system-level components, whether they are lists, hashmaps, or other references

OVER

Feel write good words, welcome to like comment collection