Cross-references and a single spy cause memory leak #1533
Comments
|
The issue is most likely caused by 2 factors:
A solution could be to make |
|
@TimvdLippe, @bric3, 🏓 |
|
@mockitoguy, hey, thanks for the reply! I think I don’t have enough expertise to do this without breaking something along the way. But just to confirm — is the issue really with Mockito or it is just a bad practices leading to this behavior? |
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 12, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their lifespan, and clean up all internal strong references associated with them. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 12, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their lifespan, and clean up all internal strong references associated with them. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 12, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their life, and clean up all internal strong references associated with them. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 12, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their life, and clean up all internal strong references associated with them. User can call MockitoSessionBuilder#trackAndCleanUpMocks() to let the session track and clean up mocks. It also relies on implementation of mock makers to cleanUpMock(Object). SubclassByteBuddyMockMaker is a intentional no-op to avoid unnecessary behavior changes in stable features. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 12, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their life, and clean up all internal strong references associated with them. User can call MockitoSessionBuilder#trackAndCleanUpMocks() to let the session track and clean up mocks. It also relies on implementation of mock makers to cleanUpMock(Object). SubclassByteBuddyMockMaker is a intentional no-op to avoid unnecessary behavior changes in stable features. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 12, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their life, and clean up all internal strong references associated with them. User can call MockitoSessionBuilder#trackAndCleanUpMocks() to let the session track and clean up mocks. It also relies on implementation of mock makers to cleanUpMock(Object). SubclassByteBuddyMockMaker is a intentional no-op to avoid unnecessary behavior changes in stable features. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 13, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their life, and clean up all internal strong references associated with them. User can call MockitoSessionBuilder#trackAndCleanUpMocks() to let the session track and clean up mocks. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 28, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their life, and clean up all internal strong references associated with them. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 28, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their life, and clean up all internal strong references associated with them. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 28, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their life, and clean up all internal strong references associated with them. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Feb 28, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their life, and clean up all internal strong references associated with them. This commit also fixes mockito#1532 and fixes mockito#1533.
ttanxu
added a commit
to ttanxu/mockito
that referenced
this issue
Mar 1, 2019
Due to the introduction of map from weak reference from mock instance to its invocation handler, Mockito became vunerable to memory leaks as there are multiple situations where Mockito could unintentionally hold strong references to mock instances in the map record. The strong references could be through spiedInstance for spies, and arguments used to faciliate method stubbing. Mockito could never know if the arguments passed in for method stubbing are also strongly referenced somewhere else or not, so Mockito needs to save a strong reference to these arguments to avoid premature GC. Therefore to solve cyclic strong references through arguments Mockito needs to explicitly know when mocks are out of their life, and clean up all internal strong references associated with them. This commit also fixes mockito#1532 and fixes mockito#1533.
|
Wow, Eclipse |
|
Just checked Mockito 2.27.0. Using the new |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Not entirely sure, but I think that Mockito does not handle cross-references well. I have a semi-complex sample that proves this, but at the same time I’m not sure it is a Mockito failure and especially a fixable one. Suggestions how to avoid this behavior in general will be very helpful!
BTW I can provide a
.hproffile if you are interested.Versions
Gradle
Heap is set to 64 MB.
Code
Eclipse Memory Analyzer
Seems like this happens:
Serviceis a spy and is being passed toComponentalong withMemoryConsumingService.Serviceis a spy it is being held by Mockito.Componentsubscribes toService.stream. Thesubscribeclosure capturesComponent,ServiceandMemoryConsumingService. Due to RxJava specificsService.streamholds all of these thanks to the closure.Serviceis being held by Mockito (since it is a spy) and by itself (due to thesubscribeclosure) Mockito does not release it.However:
component.unbind()removes a reference, so Mockito releases it and there is no OOM.Servicea spy eliminates OOM as well, i. e. cross-references are not an issue for the JVM itself.The text was updated successfully, but these errors were encountered: