blocks|key|3095737|text|一个很大的问题是，获取Java字符串的子字符串引用了原始字符串。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3095738|示例:读入一个3000个字符的记录，得到一个12个字符的子字符串，并将其返回给调用者(在同一个JVM中)。即使您没有直接引用原始字符串，该12个字符的字符串在内存中仍使用3000个字符。|3095739|对于接收并解析大量消息的系统来说，这可能是一个真正的问题。|3095740|有几种方法可以避免这种情况：|3095741|String+sub+=+new+String(str.substring(6,12));|code-block|syntax|javascript|3095742|或|3095743|String+sub+=+str.substring(6,12).intern();|3095744|第一个更加清晰。第二个还有其他含义，因为您使用的是PermGen空间。过度使用你可能会用完，除非你给你的VM足够的。|3095745|请记住，只有当你使用较小的子串，然后丢弃原始字符串，并且你经常这样做时，这才是相关的。|3095746|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|10|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

A big one is that getting substrings of Java strings refers to the original string.

Example: you read in a 3000 character record and get a substring of 12 characters, returning that to the caller (within the same JVM). Even though you don't directly have a reference to the original string, that 12 character string is still using 3000 characters in memory.

For systems that receive and then parse lots of messages, this can be a real problem.

You have a couple of ways to avoid this:

<pre><code>String sub = new String(str.substring(6,12));
</code></pre>

or

<pre><code>String sub = str.substring(6,12).intern();
</code></pre>

The first is more clearcut. The second has other implications because you're using PermGen space. Overused you could run out unless you give your VM enough.

Remember this is only relevant if you're taking small substrings and then throwing away the original string and you're doing this a lot.

blocks|key|331520|text|有没有使用dispose()方法的类？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|331521|例如java.awt.Window#dispose|offset|length|331522|331523|+public+void+dispose()|blockquote|style|BOLD|331524|331525|释放此窗口使用的所有本机屏幕资源、其子组件及其所有拥有的子项。也就是说，这些组件的资源将被销毁，它们消耗的任何内存都将返回给操作系统，并且它们将被标记为不可显示。|331526|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/javase/6/docs/api/java/awt/Window.html#dispose())^0|0|2|N|0|0|0|D|7|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@$D|Y|E|Z|1|10]]|A|$]]|$1|F|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|12|8|@$D|13|E|14|J|K]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|16|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

Any class with dispose() method?
For example <a href="http://java.sun.com/javase/6/docs/api/java/awt/Window.html#dispose()" rel="nofollow noreferrer">java.awt.Window#dispose</a>:
<blockquote>
public void dispose()
Releases all of the native screen resources used by this Window, its subcomponents, and all of its owned children. That is, the resources for these Components will be destroyed, any memory they consume will be returned to the OS, and they will be marked as undisplayable.
</blockquote>

blocks|key|3095864|text|您注册为事件接收者的所有内容，例如在GUI框架中，只要它是注册的并且事件源是活动的，就不能被垃圾回收。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3095865|如果开发人员没有意识到从事件源到事件订阅者的强引用，这可能会引入内存泄漏。|3095866|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Everything you register as the recipient of an Event, e.g. in GUI frameworks,
cannot be garbage collected as long as it is registered and the event source
is alive.

This may introduce memory leaks, if a developer is not aware of that
strong reference from the event source to the event subscriber.

blocks|key|334247|text|线程的每个实例化都会为堆栈分配内存(默认值为512k，可通过-Xss进行调整)。这本身并不是泄漏，但天真地尝试大量多线程应用程序将导致大量非明显的内存消耗。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|334248|entityMap^0|U|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Each instantiation of a Thread allocates memory for a stack (default 512k, tuneable via <code>-Xss</code>). It's not a leak as such, but a naive attempt to heavily multi-thread an application will result in a sizable non-obvious consumption of memory.

blocks|key|3308774|text|任何你持有的非静态内部类都是外部类。因此，看起来很简单内部类可以保持一个巨大的对象图。将实例放在某个静态的或应用程序范围的集合中，您将使用大量本不应该使用的内存。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3308775|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Any non-static inner classes you make hold on to outer classes. So that innocent-looking inner class can hold onto a huge object graph. Put the instance in a static or application-wide collection somewhere and you're using a lot of memory you're not supposed to be using.

blocks|key|331558|text|在弱引用已经足够的情况下使用强引用。在这里，执行自己的状态和资源管理的应用程序和API通常是罪魁祸首。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|331559|然后，使用观察者模式，这可能导致内存泄漏-当观察者从主体中删除自己时，内存不能被回收，除非主体也释放对观察者/侦听器的引用。早些时候已经指出了这一点，但没有多少人意识到即使是伐木者也是观察者。|331560|另外，there+is+the+likelihood+of+classes,+whose+objects+when+instantiated+are+automatically+placed+into+a+static+member。其中一些类甚至没有release()或dispose()方法，因此引用仍然由静态成员持有。这种类型的内存泄漏最终会导致OutOfMemory错误，并将PermGen空间问题报告为根本原因，从而使诊断更加困难。|offset|length|331561|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java^0|0|0|3|35|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Usage of strong references when weak references would have been sufficient. Application and APIs that perform their own state and resource management are the usual culprits here.

Then, there is the usage of the Observer pattern, which could lead to memory leaks - when the Observer delists itself from the Subject, memory cannot be reclaimed unless the Subject also releases the reference to the Observer/Listener. This has already been pointed out earlier, but not many people realise that even loggers are observers.

Additionally, <a href="http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java" rel="nofollow noreferrer">there is the likelihood of classes, whose objects when instantiated are automatically placed into a static member</a>. Some of these classes do not even have a release() or a dispose() method so the references continue to be held by the static member. This variety of memory leaks eventually results in a OutOfMemory error with a PermGen space issue reported as the root cause, making it more difficult to diagnose.

What classes of the Java Standard API can cause memory leaks when used in an (not obviously) incorrect way? And how can these memory leaks be avoided/fixed?

Example: <code>ObjectInputStream</code> and <code>ObjectOutputStream</code> keep references to all objects they have seen in order to send subsequent occurences of the same object as references rather than copies (and thereby deal with circular references). This causes a memory leak when you keep such a stream open indefinitely (e.g. when using it to communicate over the network).

Fix: Call reset() periodically or after each top-level object.

Memory leak traps in the Java Standard API

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

当以不正确的方式使用时，Java Standard API的哪些类会导致内存泄漏？如何避免/修复这些内存泄漏？例如：、ObjectInputStream和ObjectOutputStream保留对他们所见过的所有对象的引用，以便将同一对象的后续出现作为引用而不是副本发送(从而处理循环引用)。当您无限期地保持这样的流打开...

问Java Standard API中的内存泄漏陷阱
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java Standard API中的内存泄漏陷阱EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Java Standard API中的内存泄漏陷阱
EN