已知的 Tomcat 6.0 和 JDK 1.7.0_02 问题？
是否存在已知的 Tomcat 6.0 和 JDK 1.7.0_02 问题？
我知道如果答案是否定的，这是一个很难回答的问题。但我需要问一下，以防万一答案是肯定的。我也将接受以下问题的任何解决方案作为答案。请分享您遇到的任何问题，如果需要，我会更新这个问题。
问题：
自从从 JDK 1.7.0 升级到 1.7.0_02 以来，我遇到了一些问题（我这样做是为了避免 Eclipse 的帮助菜单由于 Java 1.7.0 错误而崩溃。）：
- Tomcat 服务器启动时间要长得多，我需要 120 秒的超时来处理它。
- 本机方法中的致命错误：JDWP 未初始化传输，jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197) 错误，该错误第二天消失，然后第三天重新出现，除了重新加载 Eclipse 之外没有任何更改。
- Tomcat 服务器需要更长的时间才能关闭。我需要 60 秒的超时来处理它，默认为 15 秒。
- 在构建工作区并验证手头的项目时，Eclipse 本身似乎慢慢停止了（打个比方）。 Eclipse 中的所有内容似乎都需要更长的时间，即使是打开未打开的文件。
一切都显得可疑。
PS JDK 1.7.0_02 也称为 1.7.0u2、Java SE 7u2、Java SE 7 Update 2版本
：
- JDK =
Oracle，64 位，从 http://www.oracle.com/technetwork/java/javase/downloads/index.html。下载并安装的确切文件是jdk-7u2-windows-x64.exe。 - Tomcat =
Tomcat 6.0.33，从 Eclipse 单独下载 - Eclipse =
面向 Web 开发人员的 Eclipse Java EE IDE。、版本：Indigo Release、Eclipse 平台，版本： 3.7.0.v20110530-9gF7UHNFFt4cwE-pkZDJ7oz-mj4OSEIlu9SEv0f，构建 ID：I20110613-1736。 - 64 位 Windows 7 计算机、8GB RAM、Intel Core i7-2600 CPU @ 3.4GHz（4 核）
- Eclipse、Tomcat、Apache HTTP Server 均位于同一台（开发）计算机上。
编辑：在上面添加了系统规格。
Are there known Tomcat 6.0 and JDK 1.7.0_02 issues?
I know this is a hard question to answer, if the answer is no. But I need to ask just in case the answer is yes. Also I will accept any solutions to the issues below as answers. Please just share whatever issues you have had, and I will update this question if need be.
Issues:
Some issues I have run into since upgrading from JDK 1.7.0 to 1.7.0_02 (which I did to avoid the Eclipse's help menus from crashing, due to a Java 1.7.0 bug.):
- Tomcat server takes much longer to start, I need a 120 second timeout to handle it.
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)error, which disappeared the next day and then reappeared the third day, with no changes other than reloading Eclipse.- Tomcat server takes much longer to shut down. I need a 60 second timeout to handle it, from 15 second default.
- Eclipse itself appears to crawl to a halt (figuratively speaking) upon building the workspace and validating the project at hand. Everything within Eclipse appears to take longer, even opening an unopened file.
Everything seems suspicious.
P.S. JDK 1.7.0_02 is also known as 1.7.0u2, Java SE 7u2, Java SE 7 Update 2, etc.
Versions:
- JDK =
Oracle, 64-bit, downloaded from http://www.oracle.com/technetwork/java/javase/downloads/index.html. Exact file downloaded and installed wasjdk-7u2-windows-x64.exe. - Tomcat =
Tomcat 6.0.33, downloaded separately from Eclipse - Eclipse =
Eclipse Java EE IDE for Web Developers.,Version: Indigo Release,Eclipse Platform,Version: 3.7.0.v20110530-9gF7UHNFFt4cwE-pkZDJ7oz-mj4OSEIlu9SEv0f,Build id: I20110613-1736. - 64-bit Windows 7 machine, 8GB RAM, Intel Core i7-2600 CPU @ 3.4GHz (4 cores)
- Eclipse, Tomcat, Apache HTTP Server, are all on the same (development) computer.
EDIT: Added system specs above.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当使用默认选项运行 64 位 Java 时（默认情况下引用压缩处于关闭状态），它需要的内存量几乎是 32 位 Java 的两倍。
对于 Eclipse，打开 eclipse.ini 文件并将
-Xmx选项加倍/增加很多。当然，在运行某些 JVM 时，您的物理内存可能会不够用。
所以我建议您测试
-XX:+UseCompressedOopsHotSpot 选项 具有 64 位 JVM，并通过jconsole监视内存使用情况。您还可以阅读有关最近选项的详细信息。该选项对于 Tomcat，创建包含以下内容的文件
bin/setenv.bat：When running 64 bits Java with default options (references compaction is off by default), it requires almost twice the amount of memory than with 32 bits.
For Eclipse, open the
eclipse.inifile and double/increase a lot the-Xmxoption.Of course, your physical memory may not be enough when running some JVMs.
So I recommend you to test the
-XX:+UseCompressedOopsHotSpot option with 64 bits JVM and monitor memory usage thanks tojconsolefor instance. You can also read details about that recent option. That optionFor Tomcat, create the file
bin/setenv.batwith content:好吧，也许这一切都与更新中发布的新JVM有关< /a>.据称它可以提高性能，但是……好吧，谁知道呢。 Tomcat6 上的 JDT 与 JDK 1.7 交互，因此可能会发生意外的情况。
除此之外，还有一些事情 检查。
Well, perhaps it's all about the new JVM released in that update. It alledgedly improves performance but... well, who knows. JDT on Tomcat6 interacts with JDK 1.7 so unexpected things could happen.
Other than that, there're few things to check.