java怎么解除文件被占用 Java程序占用内存太高了怎么办?

[更新]
·
·
分类:互联网
2854 阅读

java怎么解除文件被占用

Java程序占用内存太高了怎么办?

Java程序占用内存太高了怎么办?

1.线程有无休眠时间2.休眠时间的时长设置的是否合理。我猜测你的程序是要不停的运行来实现某种功能。这要休眠时间的设定就显得很重要了。还有就是你的功能中是否有IO,是否有耗内存的代码块,这些要看具体的才行。单纯是线程的话,注意上面两点就可以了。

localcache是什么文件?

localcache是一个纯java的在进程中的缓存文件,它具有以下特性:快速,简单,为Hibernate2.1充当可插入的缓存,最小的依赖性,全面的文档和测试。
过期失效的缓存元素无法被GC掉,时间越长缓存越多,内存占用越大,导致内存泄漏的概率越大。

gc机制?

在Java中,对象所占用的内存在对象不再使用后会自动被回收。这些工作是由一个叫垃圾回收器Garbage Collector 的进程完成的。
GC的好处是:
开发者无需过问内存管理,可以专注于解决实际问题。虽然内存泄露仍有可能会发生,但发生的概率比较小。
GC的智能算法可以在后台自动的进行内存管理,且这种管理在大多数时候是最佳的。

java web项目中如何优雅的处理异常?

Java中异常提供了一种识别及响应错误情况的一致性机制,有效地异常处理能使程序更加健壮、易于调试。异常之所以是一种强大的调试手段,在于其回答了以下三个问题:
什么出了错?在哪出的错?为什么出错?在有效使用异常的情况下,异常类型回答了“什么”被抛出,异常堆栈跟踪回答了“在哪“抛出,异常信息回答了“为什么“会抛出,如果你的异常没有回答以上全部问题,那么可能你没有很好地使用它们。有三个原则可以帮助你在调试过程中最大限度地使用好异常,这三个原则是:
具体明确提早抛出延迟捕获为了阐述有效异常处理的这三个原则
明确异常捕 获异常时尽量明确也很重要。例如:如下可以通过重新询问用户文件名来处理FileNotFoundException,对于 EOFException,它可以根据异常抛出前读取的信息继续运行。
File prefsFile new File(prefsFilename) try{ readPreferences(prefsFile) }catch (FileNotFoundException e){ // alert the user that the specified file // does not exist }catch (EOFException e){ // alert the user that the end of the file // was reached }
通过使用多个catch块来给用户提供捕获到异常的明确信息。举例来说:如果捕获了FileNotFoundException,它可以提示用户指定另一 个文件,某些情况下多个catch块带来的额外编码工作量可能是非必要的负担,但在这个例子中,额外的代码的确帮助程序提供了对用户更友好的响应。
尽早抛出异常异常堆栈信息提供了导致异常出现的方法调用链的精确顺序,包括每个方法调用的类名,方法名,代码文件名甚至行数,以此来精确定位异常出现的现场。

at (Native Method)
at ()
at ()
at ()
at ()
at ()以 上展示了FileInputStream类的open()方法抛出NullPointerException的情况。不过注意 ()是标准Java类库的一部分,很可能导致这个异常的问题原因在于我们的代码本身而不是Java API。所以问题很可能出现在前面的其中一个方法,幸好它也在堆栈信息中打印出来了。
不幸的是,NullPointerException是Java中信息量最少的(却也是最常遭遇且让人崩溃的)异常。它压根不提我们最关心的事情:到底哪里是null。所以我们不得不回退几步去找哪里出了错。
通过逐步回退跟踪堆栈信息并检查代码,我们可以确定错误原因是向readPreferences()传入了一个空文件名参数。既然readPreferences()知道它不能处理空文件名,所以马上检查该条件:
public void readPreferences(String filename) throws IllegalArgumentException{ if (filename null){ throw new IllegalArgumentException(filename is null) } //if other operations... InputStream in new FileInputStream(filename) the preferences file...}
通过提早抛出异常(又称"迅速失败"),异常得以清晰又准确。堆栈信息立即反映出什么出了错(提供了非法参数值),为什么出错(文件名不能为空值),以及哪里出的错(readPreferences()的前部分)。这样我们的堆栈信息就能如实提供:
filename is null
at ()
at ()
at ()
at ()
另外,其中包含的异常信息("文件名为空")通过明确回答什么为空这一问题使得异常提供的信息更加丰富,而这一答案是我们之前代码中抛出的NullPointerException所无法提供的。
通过在检测到错误时立刻抛出异常来实现迅速失败,可以有效避免不必要的对象构造或资源占用,比如文件或网络连接。同样,打开这些资源所带来的清理操作也可以省却。
延迟捕获菜鸟和高手都可能犯的一个错是,在程序有能力处理异常之前就捕获它。Java编译器通过要求检查出的异常必须被捕获或抛出而间接助长了这种行为。自然而然的做法就是立即将代码用try块包装起来,并使用catch捕获异常,以免编译器报错。
问 题在于,捕获之后该拿异常怎么办?最不该做的就是什么都不做。空的catch块等于把整个异常丢进黑洞,能够说明何时何处为何出错的所有信息都会永远丢失。把异常写到日志中还稍微好点,至少还有记录可查。但我们总不能指望用户去阅读或者理解日志文件和异常信息。让readPreferences()显示错误信息对话框也不合适,因为虽然JCheckbook目前是桌面应用程序,但我们还计划将它变成基于HTML的Web应用。那样的话,显示错误对话框显然不是个选择。同时,不管HTML还是C/S版本,配置信息都是在服务器上读取的,而错误信息需要显示给Web浏览器或者客户端程序。
readPreferences()应当在设计时将这些未来需求也考虑在内。适当分离用户界面代码和程序逻辑可以提高我们代码的可重用性。
那么在最外层捕获异常,统一处理:
File prefsFile new File(prefsFilename) try{ readPreferences(prefsFile) }catch (FileNotFoundException e){ // alert the user that the specified file // does not exist }catch (EOFException e){ // alert the user that the end of the file // was reached }
Spring统一处理异常如果是是Spring框架,可以使用Spring的统一异常处理机制,其他异常统统都抛出异常
public void queryUser() throws Exceptions{}@RestControllerAdvicepublic class GlobalExceptionHandler {@ExceptionHandler()public Rsp handleDefaultException(Exception exception) {if (exception instanceof HttpRequestMethodNotSupportedException) {(不支持该请求方式,只直至GET,POST)}}}
这里有一个目的就是在最上层处理业务逻辑的异常,这一条规则是明确异常(可以自定义异常来明确),尽早抛出异常,延迟捕获异常。