我们已经有一个庞大的代码库编译并开始在FlasCC中运行。当你打开.swf时，玩家的内存使用量约为300MB。它或多或少都很好，因为C ++代码似乎仍有大约300MB的动态分配内存。
我们创建线程时会出现问题。 According to documentation，每个线程都将.swf复制到内存中并在沙箱中运行。这是否意味着每个pthread都会占用玩家用来打开.swf的相同~300MB的内存？
看来是这样。我做了一个简单的测试，产生pthreads并转储内存使用情况（ flash.system.System 向我们报告，以及 CModule.ram.length ）。这是日志：
Starting 10 threads.
Memory usage: total=288MB private=335MB free=2MB CModule=33MB
Thread 0 started.
Memory usage: total=683MB private=732MB free=1MB CModule=36MB
Thread 1 started.
Memory usage: total=1071MB private=1121MB free=1MB CModule=37MB
Thread 2 started.
Memory usage: total=1459MB private=1510MB free=1MB CModule=38MB
此时plash_player_debugger退出（崩溃），没有任何错误消息。
这基本上意味着我们没有线程。启动2个pthread后，剩下的C ++代码只有大约50MB的内存。
Adobe Scout对内存使用情况进行了更深入的细分。以下是.swf使用2个后台线程运行时报告的内容：(a picture from the same question on Adobe forums)
产生这两个空闲pthreads后，“Other”块已从11到800 MB膨胀。记忆进入了“其他玩家”和“未分类”。
所以主要的问题是：如何解决这个问题？也许有办法让AS3工作者消耗更少的内存？
答案 0 :(得分：1)
如果您考虑使用AS3 workers API，则可以传递任何要执行的SWF文件。
大多数示例（在AS3中）建议传递当前的SWF字节，然后使用类似Worker.current.isPrimordial的内容来决定要做什么。
所以，虽然我认为你不能避免事实上你将拥有与线程一样多的玩家实例，但更好的方法是使worker SWF a separate module不会像主SWF那样回收更多的内存。
对于你的具体情况，我意识到这可能非常困难，因为你依赖于Adobe对worker的pthread的实现，这显然只是作为worker传入主SWF文件。此外，使用线程将现有的C / C ++代码库移动到AS3工作者远非琐碎。
