小编pxc*_*v7r的帖子

我知道这个问题已在不同的帖子中广泛讨论：

• java高效获取文件大小

• 如何在Java中获取文件大小

• 获取文件夹或文件的大小

• https://www.mkyong.com/java/how-to-get-file-size-in-java/

我的问题是我需要获取大量文件（HD 中存在的常规文件）的大小，为此我需要一个提供最佳性能的解决方案。我的直觉是应该通过直接读取文件系统表的方法来完成，而不是通过读取整个文件内容来获取文件的大小。看文档很难知道具体使用了哪种方法。

如本页所述：

Files 有 size() 方法来确定文件的大小。这是最新的 API，推荐用于新的 Java 应用程序。

但这显然不是最好的建议，就性能而言。我对不同的方法进行了不同的测量：

1. file.length();

2. Files.size(path);

3. BasicFileAttributes attr = Files.readAttributes(path, BasicFileAttributes.class); attr.size();

令我惊讶的是，这file.length();是最快的，必须创建一个File对象而不是使用较新的Path. 如果这也读取文件系统或内容，我现在不会。所以我的问题是：

在最新的 Java 版本 (9/10/11) 中，最快的、推荐的获取文件大小的方法是什么？

编辑

我认为这些细节不会为问题增加任何内容。基本上基准是这样的：

Length: 49852  with previous instanciation: 84676
Files: 3451537 with previous instanciation: 5722015
Length: 48019 with previous instanciation:: 79910
Length: 47653 with previous instanciation:: 86875
Files: 83576 with previous instanciation: 125730
BasicFileAttr: 333571 with previous instanciation:: 366928
..... …

我想知道如何在 Java 中停止一个无响应的线程，这样它就真的死了。

首先，我很清楚Thread.stop()被弃用以及为什么不应该使用它；关于这个主题已经有很多很好的答案，参见。[1] [2]。因此，更准确的问题是，从技术上讲，是否真的有可能杀死一个代码不受我们控制但可能具有敌意且不响应中断的线程。

在最简单的情况下，一个恶意线程正在运行while(true);，但它也可能耗尽内存或其他系统资源来造成更大的破坏。调用interrupt()那个线程显然是无效的。打电话stop()呢？

我已经在调试器中运行了它，事实上，线程真的消失了。但这种方法可靠吗？可以为这种情况准备敌对线程；想想try{run();}catch(ThreadDeath t){run();}它在哪里捕获ThreadDeath我们调用时产生的stop()并再次递归调用自身。

作为外部观察者，我们无法看到正在发生的事情；Thread.stop()总是默默地运行。最糟糕的是，通常的诊断将不再起作用（在 Corretto 1.8.0_275 Windows x64 上调试时试过这个）：无论是否成功杀死线程，Thread.getState()总是返回RUNNABLE，同样适用Thread.isAlive()（总是如此）。