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 putList
Object release (assigned tonull
),List
Will 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, whenperson
To be an assignmentnull
.Person@5594a1b5
This chunk of memory is stillCan be up to
We can still use itList
Visit him so he won’t beJVM
recycling
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