获得 Future进展的能力目的
参考 java.util.concurrent 包和 Future 接口，我注意到（除非我弄错了）启动冗长任务并能够查询进度的能力仅来自 SwingWorker 实现类。
这就引出了以下问题：
有没有办法在非 GUI、非 Swing 应用程序（映像控制台应用程序）中在后台启动一个冗长的任务并允许其他线程检查进度？在我看来，没有理由将此功能限制于 swing/GUI 应用程序。否则，在我看来，唯一可用的选项是通过 ExecutorService::submit 返回一个 Future 对象。但是，基本 Future 接口不允许监视进度。
With reference to the java.util.concurrent package and the Future interface I notice (unless I am mistaken) that the ability to start a lengthy tasks and be able to query on the progress only comes with the SwingWorker implementing class.
This begs the following question:
Is there a way, in a non-GUI, non-Swing application (imaging a console application) to start a lengthy task in the background and allow the other threads to inspect the progress ? It seems to me that there is no reason why this capability should be limited to swing / GUI applications. Otherwise, the only available option, the way I see it, is to go through ExecutorService::submit which returns a Future object. However, the base Future interface does not allow monitoring the progress.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
显然，Future 对象只适用于阻塞然后接收结果。
您提交的 Runnable 或 Callable 对象必须知道如何提供此进度（完成百分比、尝试计数、状态（枚举？）等）并将其作为对对象本身的 API 调用提供，或者发布在某些查找中资源（如果需要，在内存映射或数据库中）。为简单起见，我倾向于喜欢对象本身，特别是因为您很可能需要一个句柄（id）来查找对象或对对象本身的引用。
这确实意味着您有 3 个线程在运行。 1代表实际工作，1代表等待结果时被阻塞，1代表监控线程。最后一个可以根据您的要求进行共享。
Obviously, the Future object would only be good for blocking and then receiving the result.
The Runnable or Callable object that you submit would either have to know how to provide this progress (percentage complete, count of attempts, status (enum?) etc) and provide that as an API call to the object itself, or posted in some lookup resource (in memory map or database if necessary). For simplicity I tend to like the object itself, especially since you're going to most likely need a handle (id) to lookup the object or a reference to the object itself.
This does mean that you have 3 threads operating. 1 for the actual work, 1 that is blocked while waiting for the result, and 1 that is a monitoring thread. The last one could be shared depending on your requirements.
在我的例子中，我传递了一个哈希集，其中包含要处理的对象，作为方法的参数，它是在调用类中创建为实例变量的。当异步方法在处理后删除对象时，可以检索调用方法中剩余的映射的大小。我认为一般来说通过引用传递对象可以解决问题。
In my case I passed a HashSet, with the Objects to process, as Parameter to the Method, wich was created as instance variable in the calling Class. When the asyncronous method removes the Objects after processing one can retrieve the size of the Map remaining in the calling Method. I thing in general passing Objects by Reference solves the Problem.
我希望有一种标准的并发框架方法可以随时了解长时间运行的任务的进度，而不需要客户端程序担心正确编排和同步所有内容。在我看来，人们可以理解
Future界面的扩展版本，它支持：publicshortprogress();除了通常的isDone()和get()方法之外。显然，
progress()的实现需要直接轮询对象，因此可能需要将Future指定为Future; 其中CanReportProgress是以下接口：这引出了一个问题：为什么人们会费心去遍历
Future对象而不是调用对象本身来获取的进展。我不知道。我得再考虑一下。可以说它更接近当前的契约/语义，即在调用 ExecutorService::submit 后，客户端程序员不会再次访问 Callable 对象本身> /执行。I was hoping that there was a standard concurrency framework way to stay updated on the progress of a long running task without requiring the client program to worry about orchestrating and synchronizing everything correctly. It seemed to me to that one could fathom an extended version of the
Future<T>interface that would support:public short progress();in addition to the usualisDone()andget()methods.Obviously the implementation of the
progress()would then need to poll the object directly so maybeFuture<T>would need to be specified asFuture<T extends CanReportProgress>whereCanReportProgressis the following interface:This begs the question of why one would bother to go through the
Futureobject as opposed to calling the object itself to get the progress. I don't know. I'll have to give it more thought. It could be argued that it is closer to the current contract / semantics whereby theCallableobject is not, itself, accessed again by the client programmer after the call toExecutorService::submit/execute.