gwt rpc 在ie11 浏览器内存泄漏 400 请求报错

关于您提到的在IE11中使用GWT（Google Web Toolkit）2.8.0-rc3和2.8.2版本，通过定时器进行RPC轮询请求导致内存持续增长的问题，这可能是由于IE11对JavaScript垃圾回收机制的处理方式与其他现代浏览器不同所引起的。以下是一些建议，希望能帮助到您：

1. 优化DOM操作：确保每次更新UI时，尽量减少DOM的操作，因为频繁的DOM操作会增加内存消耗。考虑使用如Elemental2这样的库来更高效地操作DOM。

2. 清理事件监听器：当不再需要某个对象或组件时，确保移除其相关的事件监听器，以避免内存泄漏。在GWT中，如果使用了HandlerRegistration注册事件，记得在不再需要时调用removeHandler()方法。

3. 管理RPC回调：确保RPC请求完成后正确处理回调函数，避免它们被长时间持有，从而阻止相关对象被垃圾回收。可以考虑使用WeakReference来持有这些回调，以便于GC更容易回收。

4. 数据处理：您提到请求的数据包含时间戳等随机数，确保这些数据在使用后及时释放引用，特别是大对象或数组，避免长期占用内存。

5. 使用Chrome开发者工具进行跨浏览器调试：虽然问题出现在IE11，但可以利用Chrome或其他现代浏览器的开发者工具进行性能分析和内存快照比较，找出可能的内存泄漏点。这有助于定位是代码逻辑问题还是特定于IE的兼容性问题。

6. 尝试polyfills或shims：考虑到IE11对某些现代JavaScript特性的支持不足，可能需要引入polyfills或shims来增强兼容性，但这通常针对语言特性而非直接解决内存泄露问题。

7. 升级或替代方案：鉴于IE11的支持逐渐减少，评估是否有可能提示用户升级浏览器或转向支持更好的现代浏览器。另外，考虑GWT项目是否有迁移到其他现代化前端框架（如React, Angular, Vue.js）的可行性，这些框架在内存管理和现代浏览器兼容性方面表现更优。

8. 社区与官方资源：查阅GWT的官方文档、论坛以及GitHub issue，看是否有其他开发者遇到类似问题并分享了解决方案。有时候，特定版本的bug修复或者已知问题列表能提供直接的帮助。

希望上述建议能对您有所帮助，如果问题依旧，深入代码细节进行排查，并结合具体场景进行优化将是关键。