Is Delegate.EndInvoke() really necessary?

问题:

I've read a couple of forums and even a stackoverflow question or two saying that Delegate.EndInvoke is necessary when using Delegate.BeginInvoke. Many of the articles I've read talking about using BeginInvoke have failed to mention using EndInvoke. Also I've deployed production code using only BeginInvoke and there doesn't appear to be any memory issues. The way I've used BeginInvoke is generally with threads that I don't care about when they finish or how long they take to process.

回答1:

From the MSDN article 'Calling Synchronous Methods Asynchronously':

No matter which technique you use, always call EndInvoke to complete your asynchronous call.

Now, there is theory and then there is practice. You have found, like many other developers before you, that you can often get away with ignoring this documented requirement. It may be an implementation detail whether EndInvoke actually does anything that's absolutely necessary to prevent your application from crashing, leaking memory, etc. But here's the thing: if it's a documented requirement, you really ought to do it. This is not just about theory; it's about protecting yourself in the event of change.

By documenting this requirement, the designers of this asynchronous calling mechanism basically gave themselves the freedom to change the way BeginInvoke and EndInvoke work down the line so that, if there were sufficient reason (e.g., a performance enhancement), EndInvoke could suddenly become a lot more necessary. Suppose it would suddenly result in a deadlock if you forgot it. They've already covered themselves by saying always call EndInvoke; if your app stops working because you didn't follow this requirement, the onus is on you.

I'm not saying this is necessarily a likely scenario. My point is simply that you shouldn't—or at least I wouldn't—ask "Is this really necessary?" with the mindset of If I can get away with leaving it out, then I will, since it is documented that you should do it.

回答2:

It is absolutely necessary if you plan on throwing exceptions from your thread and expect to catch them properly. If you do not call EndInvoke, the thread that throws the exception will vanish and you won't know anything about it.

To support EndInvoke, provide an AsyncCallback, and in that callback method, be sure to wrap your call to EndInvoke with a try/catch block.

While you could get away with not doing it if you don't care about what happens in the thread, I would argue that it's a very good habit to get into to just call EndInvoke. You never know, a junior developer could some day get in there and change the code in your thread, and throw an exception. Then the updated app gets deployed, and the service calls start coming in.

回答3:

I heard sth about memory leak issues that may arises.

By a keyword search, I found a good discussion.

Does not calling EndInvoke *really* cause a memory leak ?

It can but it won't necessarily. Technically there is no such thing as a memory leak in .NET. Eventually the memory will be reclaimed by the GC. The problem is that it might be around a long time. The reason that you should call EndInvoke is because the results of the invocation (even if there is no return value) must be cached by .NET until EndInvoke is called. For example if the invoked code throws an exception then the exception is cached in the invocation data. Until you call EndInvoke it remains in memory. After you call EndInvoke the memory can be released.

Here is the reference,

Another Reference

回答4:

MSDN tells, that it is important to call EndInvoke:

Important note No matter which technique you use, always call EndInvoke to complete your asynchronous call.

回答5:

It has been documented that EndInvoke is not required (no non-managed resources are allocated—assuming you don't wait on the IAsyncResult) when using BeginInvoke to perform action on the GUI thread in a WinForms application.

However this is a specific exception to the general rule: for every BeginOperation there must be a matching EndOperation. As noted on another A here: if the GUI access code can throw, you'll need the EndInvoke to get the exception.

See here for (sort of) official confirmation: http://blogs.msdn.com/b/cbrumme/archive/2003/05/06/51385.aspx#51395 (it's the comment from Chris Brummie 12 May 2003 5:50pm.

Additional: The documentation for Control.BeginInvoke includes this remark:

You can call EndInvoke to retrieve the return value from the delegate, if neccesary, but this is not required. EndInvoke will block until the return value can be retrieved.

So it is official: with WinForm's using asynchronous delegate to perform an action on the GUI thread does not require EndInvoke (unless you need the return value or the possible exception, in either case consider using Invoke).

回答6:

The way I've used BeginInvoke is generally with threads that I don't care about when they finish or how long they take to process.

Sounds like you should consider using the Thread class instead of asynchronous delegates.

If you care about the results or detecting errors (which both require marshalling the results/error to the originating thread), then you can use asynchronous delegates, and in this case you would need EndInvoke. Better yet, use the Task or Task<TResult> classes.

If you just want to spin off some independent operation, then use the Thread class.

回答7:

From the Windows Form documentation on Control.BeginInvoke()

You can call EndInvoke to retrieve the return value from the delegate, if neccesary, but this is not required. EndInvoke will block until the return value can be retrieved.

This is the particular case of Windows Form async call on the UI thread and this this doesn't apply to the general case, yet this can help for those in this situation.