将对象存储到 JSTL 请求中的成本
我们有遗留应用程序，很快它们将开始使用常见的 jsp 页面。然而，就所使用的技术而言，他们每个人都使用不同的视图技术。很快，他们就可以在这些页面中使用jstl了。
我想将我的包实现存储在请求中，以便 JSTL 使用，就像这样
request.setAttribute("bundle", getBundle());
我们的包可能有 10000 个条目。
我的问题：
在请求中存储大对象会带来额外的成本吗？
更新：我们的捆绑包是静态的。 （每个服务器只有一个实例。）我的意思是我们在请求对象中只有一个引用。
也许我应该明确说出我的要求。已经存在的公共页面已经实现。这个实现共享一个非常不同的捆绑实现。它与 java.util.ResourceBundle 不同。这就是为什么我无法使用 jstl fmt 标签。
We have legacy applications which soon they will start to use common jsp pages. However in terms of used technologies each of them are using different view technologies. Shortly, they can use jstl in these pages.
I want to store my bundle implementation in request in order to be used by JSTL like this
request.setAttribute("bundle", getBundle());
Our bundle has maybe 10000 entry.
My question:
Does storing big objects in request bring extra cost?
Update: Our bundle is static. (Per server there is only one instance of it.) I mean that we will have just a reference in the request object.
Maybe I should clearly state my requirement. The common pages that have already existing has already implemented. And this implementation is sharing a very different bundle implementation. It is different than java.util.ResourceBundle . That is why I could not use jstl fmt tags.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您重用已经创建的包，那么我想存储不应该花费您的费用（考虑到请求也是Java对象，并且只会引用另一个包含一些对象的集合），但是如果您在每个中创建包请求调用，那么这将是昂贵的，同样不是从存储的角度来看，而是每次创建包含 10, 000 个条目的捆绑包以及垃圾收集所花费的时间。
If you are reusing already created bundle then I guess storing should not cost you (Considering the fact that - request is also Java object and will just have a reference to another collection which holds some objects), but if you are creating the bundle in each request call then that would be costly, again not from the storing perspective but time taken for creating a bundle with 10, 000 entries each time and also for garbage collection.
所有这些成本都是将对象指针填充到哈希映射中的成本，虽然不是零，但实际上为零。事实上，总共最多 20-30 个字节（取决于您主要运行的是 32b 还是 64b JVM）。
All this costs you is the cost of stuffing an object pointer in to a hash map, which is, while not zero, effectively zero. It's in fact, like, up to 20-30 bytes total (depending on whether you're running 32b or 64b JVM mostly).