gpt4 book ai didi

java - ThreadLocal 与新局部变量的真正优势

转载 作者:行者123 更新时间:2023-11-30 07:52:34 28 4
gpt4 key购买 nike

我意识到 ThreadLocal 已被多次访问,尤其是 SimpleDateFormat 示例。

但似乎即使将 SDF 设置为“ThreadLocal”,我们仍然为每个线程创建一个 SDF() 实例,这相当于调用一个新的 SDF()。

这样做一次会为每个线程提供一份 SDF 副本 -

ThreadLocal<SimpleDateFormat> sdf = new ThreadLocal<SimpleDateFormat>();

这也是——

SimpleDateFormat sdf = new SimpleDateFormat();

线程安全是通过每次复制 SDF 来简单创建的。所以我们在两种情况下都有相同数量的 SDF 实例。

那么,实例数的提升在哪里呢?

如果没有 - 为什么我要使用 ThreadLocal,而不是每次都在线程中执行 new SDF()?这样我也不用担心同步问题。

如果这个论点是正确的——我认为使用 ThreadLocal 的一个原因是它的范围。它可以是 .get() 稍后在代码的其他地方,而不用在参数中传递它。

我想确定一下,我理解正确。

谢谢。

最佳答案

ThreadLocals 有很多用途,但在包装非线程安全对象的上下文中,请考虑以下示例。
非线程本地方法很可能会崩溃,而线程本地版本则不会。

public static void main(String... args) {
MyParser parser = new MyParser();
IntStream.range(0, 100).parallel().forEach(i-> parser.parseTl("20170816"));
IntStream.range(0, 100).parallel().forEach(i-> parser.parse("20170816"));
}

static class MyParser {
private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd");
private static final ThreadLocal<SimpleDateFormat> sdftl =
ThreadLocal.withInitial(()-> new SimpleDateFormat("yyyyMMdd"));

public Date parse(String str) {
try {
return sdf.parse(str);
} catch (ParseException e) {
throw new RuntimeException(e);
}
}

public Date parseTl(String str) {
try {
return sdftl.get().parse(str);
} catch (ParseException e) {
throw new RuntimeException(e);
}
}
}

现在您可以在每次要解析日期时简单地构造一个新的格式化程序:

public Date parse(String str) {
try {
return new SimpleDateFormat("yyyyMMdd").parse(str);
} catch (ParseException e) {
throw new RuntimeException(e);
}
}

但这种方法的问题是构造 SimpleDateFormat 是一个相对较慢的操作,因此您希望构造它的次数最少。

在这种情况下当然还有其他选择,您可以同步对格式化程序的访问,但这可能比每个线程都有自己的副本要慢得多。或者您可以使用线程安全的 Java 8 java.time 格式化程序。

关于java - ThreadLocal 与新局部变量的真正优势,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45701483/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com