背景
我正在开发一个Android,它提供了一个简单的HTTP/HTTPS服务器。如果配置了HTTPS服务,那么在每个连接上都会观察到本机内存使用量的增加,这最终导致应用程序崩溃(oom),而使用HTTP配置则使本机内存使用率保持相对恒定。应用程序的Java在这两种配置中都保持相对恒定。
该应用程序提供一个HTML页面,其中包含一个带有周期性轮询的javascript (每秒一次json轮询),因此使用HTTPS配置调用应用程序页面并将页面打开几个小时将导致上述内存不足,因为增加了本机内存的使用。我已经测试了许多SSLServerSocket和SSLContext配置,发现在互联网上没有运气。
我在不同的Android设备和不同的Android版本上观察到了同样的问题,从2.2到4.3开始。
对于HTTP/HTTPS这两种配置,处理客户端请求的代码是相同的。这两种配置之间唯一的区别是服务器套接字的设置。在HTTPS套接字中,有一行类似于"ServerSocket serversocket =(Myport)“;但是对于HTTPS服务器设置,则执行通常的设置SSLContext的步骤--即设置密钥管理器和初始化SSLContext。现在,我使用默认的TrustManager。
需要你的建议
有人知道在使用OpenSSL的Android默认TLS提供程序中是否存在内存泄漏问题吗?为了避免本机内存中的泄漏,我应该考虑一些特殊的事情吗?任何暗示都是非常感谢的。
更新:我还通过在OpenSSL中显式指定提供程序名称(“SSLContext.getInstance”,providerName ),尝试了两个TLS提供者:TLS和JSSE。但这并没有改变什么。
下面是一个代码块,它演示了这个问题。只需创建一个示例应用程序,将其放到主活动的onCreate底部,然后构建并运行应用程序。确保您的Wifi处于打开状态,并通过以下地址调用HTML页面:
https://android device IP:9090然后查看adb日志,过一段时间,您将看到本机内存开始增加。
new Thread(new Runnable() {
public void run() {
final int PORT = 9090;
SSLContext sslContext = SSLContext.getInstance( "TLS" ); // JSSE and OpenSSL providers behave the same way
KeyManagerFactory kmf = KeyManagerFactory.getInstance( KeyManagerFactory.getDefaultAlgorithm() );
KeyStore ks = KeyStore.getInstance( KeyStore.getDefaultType() );
char[] password = KEYSTORE_PW.toCharArray();
// we assume the keystore is in the app assets
InputStream sslKeyStore = getApplicationContext().getResources().openRawResource( R.raw.keystore );
ks.load( sslKeyStore, null );
sslKeyStore.close();
kmf.init( ks, password );
sslContext.init( kmf.getKeyManagers(), null, new SecureRandom() );
ServerSocketFactory ssf = sslContext.getServerSocketFactory();
sslContext.getServerSessionContext().setSessionTimeout(5);
try {
SSLServerSocket serversocket = ( SSLServerSocket )ssf.createServerSocket(PORT);
// alternatively, the plain server socket can be created here
//ServerSocket serversocket = new ServerSocket(9090);
serversocket.setReceiveBufferSize( 8192 );
int num = 0;
long lastnatmem = 0, natmemtotalincrease = 0;
while (true) {
try {
Socket soc = (Socket) serversocket.accept();
Log.i(TAG, "client connected (" + num++ + ")");
soc.setSoTimeout(2000);
try {
SSLSession session = ((SSLSocket)soc).getSession();
boolean valid = session.isValid();
Log.d(TAG, "session valid: " + valid);
OutputStream os = null;
InputStream is = null;
try {
os = soc.getOutputStream();
// just read the complete request from client
is = soc.getInputStream();
int c = 0;
String itext = "";
while ( (c = is.read() ) > 0 ) {
itext += (char)c;
if (itext.contains("\r\n\r\n")) // end of request detection
break;
}
//Log.e(TAG, " req: " + itext);
} catch (SocketTimeoutException e) {
// this can occasionally happen (handshake timeout)
Log.d(TAG, "socket timeout: " + e.getMessage());
if (os != null)
os.close();
if (is != null)
is.close();
soc.close();
continue;
}
long natmem = Debug.getNativeHeapSize();
long diff = 0;
if (lastnatmem != 0) {
diff = natmem - lastnatmem;
natmemtotalincrease += diff;
}
lastnatmem = natmem;
Log.i(TAG, " answer the request, native memory in use: " + natmem / 1024 + ", diff: " + diff / 1024 + ", total increase: " + natmemtotalincrease / 1024);
String html = "<!DOCTYPE html><html><head>";
html += "<script type='text/javascript'>";
html += "function poll() { request(); window.setTimeout(poll, 1000);}\n";
html += "function request() { var xmlHttp = new XMLHttpRequest(); xmlHttp.open( \"GET\", \"/\", false ); xmlHttp.send( null ); return xmlHttp.responseText; }";
html += "</script>";
html += "</head><body onload=\"poll()\"><p>Refresh the site to see the inreasing native memory when using HTTPS: " + natmem + " </p></body></html> ";
byte[] buffer = html.getBytes("UTF-8");
PrintWriter pw = new PrintWriter( os );
pw.print("HTTP/1.0 200 OK \r\n");
pw.print("Content-Type: text/html\r\n");
pw.print("Content-Length: " + buffer.length + "\r\n");
pw.print("\r\n");
pw.flush();
os.write(buffer);
os.flush();
os.close();
} catch (IOException e) {
e.printStackTrace();
}
soc.close();
}
catch (IOException e) {
e.printStackTrace();
}
}
} catch (SocketException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
}).start();-编辑--
我上传了一个名为SSLTest for eClipse的示例应用程序项目,它演示了这个问题:
http://code.google.com/p/android/issues/detail?id=59536
--更新--
的好消息:今天发现了上面报告的安卓问题,并提交了适当的报告来修复内存泄漏。有关详细信息,请参阅上面的链接.。
发布于 2013-09-09 00:27:07
我想这将是一笔很大的时间投资,但我看到瓦兰已经移植到了Android上。你可以试着把它装起来然后跑。当然,如果您发现有内部内存泄漏,那么除了试图在将来的Android版本中修复这个错误之外,没有什么可以做的。
作为解决办法,您可以使您的应用程序多进程,并将https服务放在一个单独的进程中。这样您就可以定期重新启动它,从而避免OOM。您还可能需要有第三个进程,只需接受端口443连接并将它们传递给https工作者,以便在https工作者重新启动时避免微小的中断。
这听起来也像是一笔大量的时间投资:),但它可能成功地避免了这个问题。
编辑:更多细节--
是的,如果您有一个具有自己的UI的主应用程序,一个用于处理SSL的辅助进程,以及一个用于接受SSL请求的辅助进程(正如您所说的可能不是443),那么在您的正常活动类之上,您将有两个Service类,并且清单将它们放置在不同的进程中。
处理SSL进程:与其等待OOM使服务崩溃,该服务可以监视自己的Debug.getNativeHeapSize(),并在服务增加太多时显式地重新启动服务。或者,或者在每100次请求之后自动重新启动。
处理侦听套接字进程:此服务只侦听您选择的TCP端口,并将原始数据传递给SSL进程。这一点需要考虑一下,但最明显的解决方案是让SSL进程侦听不同的本地端口X (或在选择的不同端口之间切换),侦听套接字进程会将数据转发到端口X。允许侦听套接字进程的原因是优雅地处理X下降的可能性--就像每次重新启动它时一样。
如果您的需求允许偶尔出现小故障--我只需要处理SSL过程,跳过侦听套接字过程,这是一个相对简单的解决方案--与您通常所做的没有什么不同。监听套接字过程增加了解决方案的复杂性.
发布于 2013-09-06 14:08:11
显式关闭输入流是否有帮助?在示例代码中,输入流似乎只在SocketTimeoutException异常情况下才被关闭。
-编辑--
您可以将run()重命名为run2(),并将while循环移到run()中,并从run2()中删除它,看看这是否有区别?这不可能是一个解决方案,但会告诉您是否有任何长期存在的对象在其引用被删除时释放内存。
发布于 2013-09-10 13:19:04
我建议在您的实现中更改一个细节。
列出所有的资源变量,例如Socket、Streams、Writers等。确保在try语句之外有声明,并确保在finally语句中进行清理/关闭。我通常这样做是为了百分之百肯定:
InputStream in = null;
OutputStream out = null;
try {
//assign a proper value to in and out, and use them as needed.
} catch(IOException e) {
//normal error handling
} finally {
try {
in.close();
} catch(IOException e) {}
try {
out.close();
} catch(IOException e) {}
}它看起来有点混乱,但是假设您在try块中使用inside,得到一些异常,那么您的流就永远不会关闭,这是内存泄漏的一个潜在原因。
我不能保证这就是原因,但这应该是一个很好的起点。
关于管理你的服务。我在Android服务方面有很多不好的经验,因为我在与GUI相同的线程中运行这些服务。在某些情况下,Android会看到一些执行时间太长的代码,为了防止崩溃,它会杀死您的主进程。我找到的解决方案是遵循本教程的建议(参见第4点):
http://www.vogella.com/articles/AndroidServices/article.html
在此之后,我的服务就像预期的那样工作了,并且没有干扰我的GUI过程。
问候
https://stackoverflow.com/questions/18484514
复制相似问题