问题
Do you need to unsubscribe from Angular 2 http calls to prevent memory leak?
fetchFilm(index) {
var sub = this._http.get(`http://example.com`)
.map(result => result.json())
.map(json => {
dispatch(this.receiveFilm(json));
})
.subscribe(e=>sub.unsubscribe());
...
回答1:
So the answer is no, you don't. Ng2 will clean it up itself.
The Http service source, from Angular's Http XHR backend source:
Notice how it runs the complete() after getting the result. This means it actually unsubscribes on completion. So you don't need to do it yourself.
Here is a test to validate:
fetchFilms() {
return (dispatch) => {
dispatch(this.requestFilms());
let observer = this._http.get(`${BASE_URL}`)
.map(result => result.json())
.map(json => {
dispatch(this.receiveFilms(json.results));
dispatch(this.receiveNumberOfFilms(json.count));
console.log("2 isUnsubscribed",observer.isUnsubscribed);
window.setTimeout(() => {
console.log("3 isUnsubscribed",observer.isUnsubscribed);
},10);
})
.subscribe();
console.log("1 isUnsubscribed",observer.isUnsubscribed);
};
}
As expected, you can see that it is always unsubscribed automatically after getting the result and finishing with the observable operators. This happens on a timeout (#3) so we can check the status of the observable when it's all done and completed.
And the result
So, no leak would exist as Ng2 auto unsubscribes!
Nice to mention: This Observable is categorized as finite, on contrary to the infinite Observablewhich is an infinite stream of data can be emitted like DOM click listener for example.
THANKS, @rubyboy for help on this.
回答2:
What are you people talking about!!!
OK so there's two reasons to unsubscribe from any observable. Nobody seems to be talking much about the very important second reason!
1) Clean up resources. As others have said this is a negligible problem for HTTP observables. It'll just clean itself up.
2) Prevent the
subscribehandler from being run.
(For HTTP this actually will also cancel the request in the browser - so it won't waste time reading the response. But that's actually an aside to my main point below.)
The relevance of number 2 is going to depend upon what your subscribe handler does:
If your
subscribe()handler function has any kind of side effect that is undesired if whatever calls it is closed or disposed then you must unsubscribe (or add conditional logic) to prevent it from being executed.
Consider a few cases:
1) A login form. You enter username and password and click 'Login'. What if the server is slow and you decide to hit Escape to close the dialog? You'll probably assume you weren't logged in, but if the http request returned after you hit escape then then you will still execute whatever logic you have there. This may result in a redirect to an account page, an unwanted login cookie or token variable being set. This is probably not what your user expected.
2) A 'send email' form.
If the subscribe handler for 'sendEmail' does something like trigger a 'Your email is sent' animation, transfer you to a different page or tries to access anything that has been disposed you may get exceptions or unwanted behavior.
Also be careful not to assume unsubscribe() means 'cancel'. Once the HTTP message is in-flight unsubscribe() will NOT cancel the HTTP request if it's already reached your server. It will only cancel the response coming back to you. And the email will probably get sent.
If you create the subscription to send the email directly inside a UI component then you probably would want to unsubscribe on dispose, but if the email is being sent by a non-UI centralized service then you probably wouldn't need to.
3) An Angular component that is destroyed / closed. Any http observables still running at the time will complete and run their logic unless you unsubscribe in onDestroy(). Whether the consequences are trivial or not will depend upon what you do in the subscribe handler. If you try to update something that doesn't exist anymore you may get an error.
Sometimes you may have some actions you would want if the component is disposed, and some you wouldn't. For example maybe you have a 'swoosh' sound for a sent email. You'd probably want this to play even if the component was closed, but if you try to run an animation on the component it would fail. In that case some extra conditional logic inside subscribe would be the solution - and you would NOT want to unsubscribe the http observable.
So in answer to the actual question, no you don't need to do it to avoid memory leaks. But you need to do it (often) to avoid unwanted side effects being triggered by running code that may throw exceptions or corrupt your application state.
Tip: The Subscription contains a closed boolean property that may be useful in advanced cases. For HTTP this will be set when it completes. In Angular it might be useful in some situations to set a _isDestroyed property in ngDestroy which can be checked by your subscribe handler.
Tip 2: If handling multiple subscriptions you can create an ad-hoc new Subscription() object and add(...) any other subscriptions to it - so when you unsubscribe from the main one it will unsubscribe all the added subscriptions too.
回答3:
Calling the unsubscribe method is rather to cancel an in-progress HTTP request since this method calls the abort one on the underlying XHR object and remove listeners on the load and error events:
// From the XHRConnection class
return () => {
_xhr.removeEventListener('load', onLoad);
_xhr.removeEventListener('error', onError);
_xhr.abort();
};
That said, unsubscribe removes listeners... So it could be a good idea but I don't think that it's necessary for a single request ;-)
Hope it helps you, Thierry
回答4:
Also with the new HttpClient module, remains the same behaviour
回答5:
You shouldn't unsubscribe from observables that completes automatically (e.g Http, calls). But it's necessary to unsubscribe from infinite observables like Observable.timer().
回答6:
Unsubscribing is a MUST if you want a deterministic behavior on all network speeds.
Imagine that component A is rendered in a tab - You click a button to send a 'GET' request out. It takes 200 ms for the response to come back. So, you are safe to close the tab at any moment knowing that, the machine will be faster than you & the http response is processed and is complete before the tab is closed and component A is destroyed.
How about on a very slow network? You click a button, the 'GET' request takes 10 seconds to receive its response, but 5 seconds into waiting you decide to close the tab. That will destroy component A to be garbage-collected at a later time. Wait a minute!, we did not unsubscribe -- now 5 seconds later, a response comes back and the logic in the destroyed component will be execute. That execution is now considered out-of-context and can result in many things including very low performance.
So, best practice is to use takeUntil() and unsubscribe from http calls when the component is destroyed.
import { Component, OnInit, OnDestroy } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';
interface User {
id: string;
name: string;
age: number;
}
@Component({
selector: 'app-foobar',
templateUrl: './foobar.component.html',
styleUrls: ['./foobar.component.scss'],
})
export class FoobarComponent implements OnInit, OnDestroy {
private user: User = null;
private destroy$ = new Subject();
constructor(private http: HttpClient) {}
ngOnInit() {
this.http
.get<User>('api/user/id')
.pipe(takeUntil(this.destroy$))
.subscribe(user => {
this.user = user;
});
}
ngOnDestroy(): void {
this.destroy$.next(); // trigger the unsubscribe
this.destroy$.complete(); // finalize & clean up the subject stream
}
}
回答7:
You should definitely read this article. It shows you why you should always unsubscribe even from http.
If after creating the request but before receiving an answer from the back-end you deem the component unnecessary and destroy it, your subscription will maintain the reference to the component thus creating a chance for causing memory leaks.
Update
The above affirmation seems to be true, but anyway, when the answer comes back the http subscription is destroyed anyway
回答8:
RxJS observable are basically associated and work accordingly you subscribe it. When we create the observable and the movement we complete it, observable automatically gets closed and unsubscribed.
They work in the same fashion of the watchers but quite different order. The better practice to unsubscribe them when component is getting destroy.We could subsequently do that by eg. this.$manageSubscription.unsubscibe()
If we have created the observable like below mentioned syntax such as
** return new Observable((observer) => { ** // It makes observable in cold state ** observer.complete() **}) **
来源：https://stackoverflow.com/questions/35042929/is-it-necessary-to-unsubscribe-from-observables-created-by-http-methods