小编Ars*_*sen的帖子

Java:通过2D float(float [] [])数组减少内存消耗

我有Java应用程序,它集中使用2D浮点数组(float [] []数组),实际上在黑色背景上保存图像.两个维度都是等于(正方形)并且是2的幂(大多数是256,512,1024),因此在大多数情况下,靠近边界的区域具有零.

大小等于2的功率以提高性能(存在一些FFT)并且降低了那些阵列上的操作的复杂性,例如旋转等.最近我在6Gb的机器上面临这个应用程序的堆缺乏.通过我的计算 - 这个应用程序的内存消耗应该高达2-3Gb,而它达到4-5Gb(在Windows任务管理器中查看).我使用了"YourKit"分析器,它显示那些浮点数阵列确实占用了大部分内存,但是,这些浮点数组的总粗略大小应该是1.3Gb(嗯,我知道由JVM决定如何存储数据,但是我没想到内存消耗会有2-3倍的差异.

我试图使用Snappy压缩器动态压缩/解压缩数据(并且内存消耗降至3.5Gb),但性能下降了几次,这是不可接受的.此外,我在BufferedImage替换那些浮动[] []时测试性能,但性能非常差.

因此,还有两种方法可以减少内存消耗:1)为float [] []数组写包装器以保存"零"元素(有很多"空"行和列)2 )远离"2的力量"

这两种方式都需要相当多的编码/重构,所以当我想"成为或不成为"时 - 你可能对这个问题有更好的线索,伙计们？

谢谢!

java arrays fft out-of-memory memory-optimization

Ars*_*sen

2013 11-08

5
推荐指数

1
解决办法

336
查看次数

SOLR性能

我在我的项目中使用 SolrJ + Solr。问题是我在 Solr/Jetty 方面遇到了不清楚的瓶颈

使用 jvisualvm 我连接到 JVM 实例，Solr 在该实例下启动并看到 77% 的时间花在方法“org.eclipse.jetty.io.ByteArrayBuffer.readFrom()”上，其中一个线程的堆栈跟踪如下：

"qtp64700533-36718" - Thread t@36718
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:152)
    at java.net.SocketInputStream.read(SocketInputStream.java:122)
    at org.eclipse.jetty.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:391)
    at org.eclipse.jetty.io.bio.StreamEndPoint.fill(StreamEndPoint.java:141)
    at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.fill(SocketConnector.java:227)
    at org.eclipse.jetty.http.HttpParser.fill(HttpParser.java:1040)
    at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:280)
    at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
    at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
    at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
    at java.lang.Thread.run(Thread.java:745)

Run Code Online (Sandbox Code Playgroud)

所以，花在 I/O 上的时间看起来没问题，但是：