从Java 6升级到Java 7时，原生堆上的OutOfMemoryError 7(OutOfMemoryError on native heap when upgrading from java 6 to java 7)
我们最近将我们的大型webapp（运行在jboss 5上）从java 6升级到java 7。
在几个小时内，我们看到了一个OutOfMemory错误，它看起来像是本地堆已经用完了。
我们正在运行32位JVM，因此被限制为4GB，并且JVM被分配了2GB。
在java 6下，整个过程占用大约2.3GB，但是使用java 7后，这个数量大大增加了，并且我们达到了4GB的限制，但没有触发完整的GC，因为Java堆还没有满。
堆栈跟踪显示XML解组代码正在为每个请求创建新的SAXParserFactory，并且用于解压缩jar文件的Inflater类将大量数据存储在本地堆（大约200,000个Inflater实例）中。 这让我觉得效率相当低 - 无论是新的SAXParserFactory还是多个Inflater。 也许这是一个红鲱鱼，但我没有Java 6版本来比较行为。
通过每隔几个小时手动运行一次gc，应用程序就会快乐地连续几天没有任何问题地出现。 但这不是一个解决方案。
问题是为什么内存分配增加了1.5GB，我该如何阻止这种情况发生？
我希望更新的java版本更高效，更快速等等。 但是，我们在JVM中看起来像是内存泄漏。
无论如何，堆栈跟踪如下所示：
# There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (malloc) failed to allocate 512128 bytes for Chunk::new # An error report file with more information is saved as: # /opt/SP/apps/er_core/current/hs_err_pid25455.log 00:49:30,072 ERROR [[DecouplingProcessServlet]] Servlet.service() for servlet DecouplingProcessServlet threw exception java.lang.OutOfMemoryError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.<init>(Inflater.java:101) at java.util.zip.ZipFile.getInflater(ZipFile.java:450) at java.util.zip.ZipFile.getInputStream(ZipFile.java:369) at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.openStream(ZipFileWrapper.java:214) at org.jboss.virtual.plugins.context.zip.ZipEntryContext.openStream(ZipEntryContext.java:1066) at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.openStream(ZipEntryHandler.java:153) at org.jboss.virtual.VirtualFile.openStream(VirtualFile.java:230) at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getInputStream(VirtualFileURLConnection.java:93) at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:233) at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:94) at java.security.AccessController.doPrivileged(Native Method) at javax.xml.parsers.SecuritySupport.getResourceAsStream(SecuritySupport.java:87) at javax.xml.parsers.FactoryFinder.findJarServiceProvider(FactoryFinder.java:283) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:255) at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:126) at javax.xml.bind.helpers.AbstractUnmarshallerImpl.getXMLReader(AbstractUnmarshallerImpl.java:100) at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157) at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:204) at com.mycompany.global.er.decoupling.util.xml.JAXBHelper.bind(JAXBHelper.java:88) at com.mycompany.global.er.decoupling.util.xml.JAXBHelper.bind(JAXBHelper.java:56) at com.mycompany.global.er.decoupling.DecouplingProcessServlet.doPost(DecouplingProcessServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:269) at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:81) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at pk.vodafone.valves.PKAccessLogValve.invoke(PKAccessLogValve.java:547) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:724) 00:49:30,117 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.NoClassDefFoundError: javax/servlet/ServletRequestAttributeEvent at org.apache.catalina.connector.Request.setAttribute(Request.java:1452) at org.apache.catalina.core.StandardWrapperValve.exception(StandardWrapperValve.java:523) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:280) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:269) at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:81) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at pk.vodafone.valves.PKAccessLogValve.invoke(PKAccessLogValve.java:547) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:724) Caused by: java.lang.ClassNotFoundException: Unexpected error during load of: javax.servlet.ServletRequestAttributeEvent, msg=null at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:173) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:259) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1102) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:772) at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:415) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 19 more Caused by: java.lang.OutOfMemoryError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.<init>(Inflater.java:101) at java.util.zip.ZipFile.getInflater(ZipFile.java:450) at java.util.zip.ZipFile.getInputStream(ZipFile.java:369) at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.openStream(ZipFileWrapper.java:214) at org.jboss.virtual.plugins.context.zip.ZipEntryContext.openStream(ZipEntryContext.java:1066) at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.openStream(ZipEntryHandler.java:153) at org.jboss.virtual.VirtualFile.openStream(VirtualFile.java:230) at org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.getResourceAsStream(VFSClassLoaderPolicy.java:483) at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:508) at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:506) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:504) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:481) at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134) at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131) at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452) at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:258) at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:152) ... 24 more [thread 123611 also had an error]更新
多一点分析。 以下是我对xml解析发生了什么的简单解释：
我们有一个单例JAXBHelper类，带有一个实例级JAXBContext （这是一个线程安全对象）。 每次请求进入时，我们都会尝试将传入的xml字符串绑定到Java对象（以前由JAXB从xsd生成）。 绑定方法创建一个实例级别的解组器（这些不是线程安全的，但创建便宜）。 然后bind方法调用unmarshaller的unmarshal(InputStream)方法。 现在， javax.xml.bind.helpers.AbstractUnmarshallerImpl然后调用SAXParserFactory.newInstance ，而SAXParserFactory.newInstance又调用一个类加载器，而后者又需要一个Inflater 。实际上（我们使用jaxb-ri 2.2.7）应该保留SAXParserFactory或SAXParser并重新使用它们？ 我注意到，既不是线程安全的，也可以用ThreadLocal来完成。 或者Inflater实例是否可以重新使用？
那么这些不被重新使用的事实是否意味着我不是取消引用我的对象？ UnMarshaller似乎没有任何一种密切的方法。
We recently upgraded our large webapp (running on jboss 5) from java 6 to java 7.
Within hours, we saw an OutOfMemory error, and it looks like it's the native heap which ran out.
We are running 32 bit JVM so are limited to 4GB, and the JVM was allocated 2GB.
Under java 6 the whole process occupied about 2.3GB, but with java 7 this is greatly increased, and we hit the 4GB limit without a full GC being triggered because the Java heap was still not full.
The stack trace showed that the XML unmarshalling code is creating new SAXParserFactory on each request, and the Inflater class for unzipping the jar file stores loads of data in the native heap (~200,000 Inflater instances). This strikes me as fairly inefficient - both the new SAXParserFactory and the multiple Inflaters. Maybe this is a red herring, but I don't have the java 6 version of this to compare behaviours.
By running the gc manually every few hours, the application ticks happily along for days without any problems. But that's not a solution.
The question is why has the memory allocation increased by a whopping 1.5GB, and how do I stop that happening?
I would expect a newer java version be more efficient, faster and so on. But instead we have what looks like a memory leak in the JVM.
Anyway the stack trace is as follows:
# There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (malloc) failed to allocate 512128 bytes for Chunk::new # An error report file with more information is saved as: # /opt/SP/apps/er_core/current/hs_err_pid25455.log 00:49:30,072 ERROR [[DecouplingProcessServlet]] Servlet.service() for servlet DecouplingProcessServlet threw exception java.lang.OutOfMemoryError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.<init>(Inflater.java:101) at java.util.zip.ZipFile.getInflater(ZipFile.java:450) at java.util.zip.ZipFile.getInputStream(ZipFile.java:369) at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.openStream(ZipFileWrapper.java:214) at org.jboss.virtual.plugins.context.zip.ZipEntryContext.openStream(ZipEntryContext.java:1066) at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.openStream(ZipEntryHandler.java:153) at org.jboss.virtual.VirtualFile.openStream(VirtualFile.java:230) at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getInputStream(VirtualFileURLConnection.java:93) at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:233) at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:94) at java.security.AccessController.doPrivileged(Native Method) at javax.xml.parsers.SecuritySupport.getResourceAsStream(SecuritySupport.java:87) at javax.xml.parsers.FactoryFinder.findJarServiceProvider(FactoryFinder.java:283) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:255) at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:126) at javax.xml.bind.helpers.AbstractUnmarshallerImpl.getXMLReader(AbstractUnmarshallerImpl.java:100) at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157) at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:204) at com.mycompany.global.er.decoupling.util.xml.JAXBHelper.bind(JAXBHelper.java:88) at com.mycompany.global.er.decoupling.util.xml.JAXBHelper.bind(JAXBHelper.java:56) at com.mycompany.global.er.decoupling.DecouplingProcessServlet.doPost(DecouplingProcessServlet.java:163) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:269) at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:81) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at pk.vodafone.valves.PKAccessLogValve.invoke(PKAccessLogValve.java:547) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:724) 00:49:30,117 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.NoClassDefFoundError: javax/servlet/ServletRequestAttributeEvent at org.apache.catalina.connector.Request.setAttribute(Request.java:1452) at org.apache.catalina.core.StandardWrapperValve.exception(StandardWrapperValve.java:523) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:280) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) at org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:269) at org.apache.catalina.valves.RemoteAddrValve.invoke(RemoteAddrValve.java:81) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at pk.vodafone.valves.PKAccessLogValve.invoke(PKAccessLogValve.java:547) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:724) Caused by: java.lang.ClassNotFoundException: Unexpected error during load of: javax.servlet.ServletRequestAttributeEvent, msg=null at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:173) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:259) at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1102) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:772) at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:415) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 19 more Caused by: java.lang.OutOfMemoryError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.<init>(Inflater.java:101) at java.util.zip.ZipFile.getInflater(ZipFile.java:450) at java.util.zip.ZipFile.getInputStream(ZipFile.java:369) at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.openStream(ZipFileWrapper.java:214) at org.jboss.virtual.plugins.context.zip.ZipEntryContext.openStream(ZipEntryContext.java:1066) at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.openStream(ZipEntryHandler.java:153) at org.jboss.virtual.VirtualFile.openStream(VirtualFile.java:230) at org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.getResourceAsStream(VFSClassLoaderPolicy.java:483) at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:508) at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:506) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:504) at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:481) at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134) at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131) at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452) at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:258) at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:152) ... 24 more [thread 123611 also had an error]Update
A bit more analysis. Here's my naive interpretation of what's happening with the xml parsing:
We have a singleton JAXBHelper class, with an instance-level JAXBContext (this is a threadsafe object). Every time a request comes in, we attempt to bind the incoming xml string to a Java object (generated previously by JAXB from the xsd). The bind method creates an instance-level unmarshaller (these are not threadsafe, but cheap to create). The bind method then calls the unmarshaller's unmarshal(InputStream) method. Now the javax.xml.bind.helpers.AbstractUnmarshallerImpl then calls SAXParserFactory.newInstance, which in turn calls a classloader, which in turn requires an Inflater.Surely the implementation (we're using jaxb-ri 2.2.7) should keep the SAXParserFactory or the SAXParser and re-use them? I note that neither are threadsafe, so it could be done with a ThreadLocal. Or could the Inflater instances be re-used?
Does that fact that these are not being re-used mean that I'm not dereferencing my objects? The UnMarshaller doesn't seem to have any kind of close method.
最满意答案
内存泄漏是由未关闭的Inflater引起的。 它看起来像这些充气器属于老一代，只要不触发Full GC，它们的终结器就不会被调用。
为了防止JRE扫描所有查找SAXParserFactory的JAR文件，可以创建包含以下行的$JAVA_HOME/jre/lib/jaxp.properties文件：
javax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl删除-XX:+DisableExplicitGC选项可能也很有用，因为JVM运行时检测到本机内存不足时依赖于System.gc调用。
The memory leak is caused by Inflaters that are not closed. It looks like these Inflaters fall down to Old Generation and their finalizers are not called as long as Full GC is not triggered.
In order to prevent JRE from scanning through all JAR files looking for SAXParserFactory, you may create $JAVA_HOME/jre/lib/jaxp.properties file containing the following line:
javax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImplIt might be also useful to remove -XX:+DisableExplicitGC option since JVM runtime depends on System.gc call when it detects a shortage of native memory.
更多推荐
发布评论