Tomcat 5.5 和 Tomcat 中运行功能的数据损坏问题6.0
几天来我一直在试图找出这个错误。我已将问题缩小到一个测试用例,如下所示。同样,这是一个导致错误发生的测试用例。该功能(此时)并不是一个实用的功能,而只是试图找出错误。
服务器正在运行: - 雄猫6 - OpenJDK 1.6.0_17 - CentOS 5.5
我有一个简单的类文件,其中包含以下方法静态方法和静态变量声明:
public static java.text.SimpleDateFormat displayDateSDF1 = new java.text.SimpleDateFormat("MM/dd/yyyy");
public static java.util.Date getSubDateMini(String inputDate)
{
java.util.Date testObj = null;
try
{
testObj = displayDateSDF1.parse("01/01/2000") ;
}
catch (Exception e)
{
}
return testObj;
}
在 Tomcat 中测试:
当我运行此方法时,我希望每次都能得到相同的结果,对吧?但是,如果我从 JSP 调用此方法,大约 99.9% 的情况下我会得到值为 1/1/2000 的 Date 对象的预期结果。然而,有时我会得到一个意外的数据对象,并且带有看似随机的日期值。
为了测试这一点,我创建了一个包含以下代码段的 JSP:
for (int i=0; i<200000;i++)
{
java.util.Date testObjLib = TestDate.getSubDateMini("") ;
if (testObjLib!=null&&!testObjLib.toString().equalsIgnoreCase("Sat Jan 01 00:00:00 PST 2000"))
{
out.print("<br>"+testObjLib+"");
}
}
显示的一些日期如下:
Wed Jan 01 00:00:00 PST 1
Fri Aug 01 00:00 :00 PDT 2166
在 200,000 次运行中,我得到大约 50 个错误日期,错误率约为 0.025%,但它又是随机的。我已经运行此循环 10 次迭代并收到错误。有时它会以 200,000 的值运行循环,并且所有日期看起来都不错。
在 Java 中测试:
通过 CentOS 中的控制台/终端应用程序使用相同的循环运行此循环,我还没有看到此错误发生。我将循环增加到 10,000,000 次,到目前为止还没有错误的结果。
我可以理解内存不足或抛出一些错误(这将导致空值),但不能理解数据损坏/不一致。我使用 Tomcat 6 从头开始构建了一个新服务器,并尝试了 Tomcat 5.5,两者都有相同的结果。我还没有尝试过 Tomcat 7。
有什么建议吗?
I've been trying to figure out this bug for few days. I have narrowed the issue down to a test case as follows. Again, this is a test case that causes the bug to happen. The function (at this point) is not a practical one, but just trying to figure out the bug.
Server is running:
- Tomcat 6
- OpenJDK 1.6.0_17
- CentOS 5.5
I have a simple Class file with the following method Static Method and Static variable declaration:
public static java.text.SimpleDateFormat displayDateSDF1 = new java.text.SimpleDateFormat("MM/dd/yyyy");
public static java.util.Date getSubDateMini(String inputDate)
{
java.util.Date testObj = null;
try
{
testObj = displayDateSDF1.parse("01/01/2000") ;
}
catch (Exception e)
{
}
return testObj;
}
Testing in Tomcat:
When I run this method, I'd expect to get the same result every time, right? However, if I call this method from a JSP, I get the expected result of a Date object with value 1/1/2000 about 99.9% of the time. However, sometimes I get an unexpected data object passed back with a seemingly random date value.
To test this, I created a JSP with the following code segment in it:
for (int i=0; i<200000;i++)
{
java.util.Date testObjLib = TestDate.getSubDateMini("") ;
if (testObjLib!=null&&!testObjLib.toString().equalsIgnoreCase("Sat Jan 01 00:00:00 PST 2000"))
{
out.print("<br>"+testObjLib+"");
}
}
Some dates that appear are as follows:
Wed Jan 01 00:00:00 PST 1
Fri Aug 01 00:00:00 PDT 2166
In 200,000 runs, I get approximately 50 bad dates which gives an error rate of ~0.025% but again it's random. I've run this loop with 10 iterations and received an error. Sometimes it runs the loop with 200,000 and all dates look good.
Testing in Java:
Running this loop via a console/terminal app in CentOS with the same loop, I have not seen this error happen yet. I increased the loop to 10,000,000 and had no false results as of yet.
I can understand out of memory or some thrown error (which would result in a null value) but not corrupt/inconsistent data. I built up a new server from scratch with Tomcat 6 and also tried Tomcat 5.5 and both have the same results. I have not tried Tomcat 7.
Any suggestions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
SimpleDateFormat
不是线程安全的。这意味着当从多个线程访问它时,可能会观察到意外的结果。 Tomcat 是从一个单独的线程处理每个请求,因此每当两个请求同时发出时,就会出现问题。
您有多种选择:
SimpleDateFormat
(而不是使其静态
),ThreadLocal
来存储它。DateTimeFormat
是线程安全的。SimpleDateFormat
is not thread-safe.This means that when it is accessed from multiple threads, unexpected results can be observed. And tomcat is serving each request from a separate thread, so whenever two requests are made at the same time, the problem would arise.
You have a number of options:
SimpleDateFormat
on each call of the method (rather than making itstatic
)ThreadLocal
to store it.DateTimeFormat
is thread-safe.