网站流量一直做不起来,旅游网站建设步骤,生活中好的设计产品,建网站外包公司织机原理为什么为什么#xff1f; Java 8流背后的驱动程序之一是并发编程。 在流管道中#xff0c;指定要完成的工作#xff0c;然后任务将自动分配到可用处理器上#xff1a; var result myData.parallelStream().map(someBusyOperation).reduce(someAssociativeBinOp)… 织机原理 为什么为什么 Java 8流背后的驱动程序之一是并发编程。 在流管道中指定要完成的工作然后任务将自动分配到可用处理器上 var result myData.parallelStream().map(someBusyOperation).reduce(someAssociativeBinOp).orElse(someDefault); 当数据结构便宜且可拆分成多个部分且操作使处理器繁忙时并行流将发挥出色的作用。 这就是它的设计目的。 但是如果您的工作负载包含大部分阻塞的任务那么这对您没有帮助。 那是您典型的Web应用程序可以处理许多请求每个请求都花费大量时间等待REST服务数据库查询等结果。 1998年令人惊奇的是Sun Java Web ServerTomcat的前身在单独的线程而不是OS进程中运行每个请求。 这样就可以满足数千个并发请求 如今这并不令人惊讶。 每个线程占用大量内存典型服务器上不能有数百万个线程。 这就是为什么服务器端编程的现代口号是“永不阻塞” 相反您指定一旦数据可用就应该发生什么。 这种异步编程风格非常适合服务器使它们可以轻松支持数百万个并发请求。 对于程序员来说不是那么好。 这是使用HttpClient API的异步请求 HttpClient.newBuilder().build().sendAsync(request, HttpResponse.BodyHandlers.ofString()).thenAccept(response - . . .);.thenApply(. . .);.exceptionally(. . .); 我们通常用语句实现的功能现在被编码为方法调用。 如果我们喜欢这种编程风格就不会在Lisp中使用我们的编程语言来编写语句和编写快乐的代码。 诸如JavaScript和Kotlin之类的语言为我们提供了“异步”方法在该方法中我们编写语句然后将这些语句转换为您刚刚看到的方法调用。 很好只不过它意味着现在有两种方法-常规方法和转换方法。 而且您不能混合使用它们“红色药丸/蓝色药丸”分界。 Project Loom从Erlang和Go等语言中获得指导在这些语言中阻塞并不是什么大问题。 您可以在“光纤”或“轻型线程”或“虚拟线程”中运行任务。 该名称尚待讨论但我更喜欢“光纤”因为它很好地表示了多个光纤在一个承载线程中执行的事实。 当发生阻塞操作例如等待锁定或I / O时光纤将停放。 停车比较便宜。 如果很多时候都停放了一根载运纤维则可以支撑一千根纤维。 请记住Project Loom不能解决所有并发问题。 如果您有大量计算任务并且想让所有处理器内核都忙它对您无济于事。 它对使用单个线程的用户界面没有帮助用于序列化对不是线程安全的数据结构的访问。 在该用例中继续使用AsyncTask / SwingWorker / JavaFX Task 。 当您有很多任务花费大量时间阻塞时Project Loom很有用。 注意 如果您已经待了很长时间您可能还记得Java的早期版本具有映射到OS线程的“绿色线程”。 但是有一个关键的区别。 当绿色线程被阻塞时其承载线程也被阻塞从而阻止了同一承载线程上的所有其他绿色线程取得进展。 踢轮胎 在这一点上Project Loom仍处于探索阶段。 API会不断变化因此在假期过后尝试使用该代码时请准备好适应最新的API版本。 您可以从http://jdk.java.net/loom/下载Project Loom的二进制文件但是它们很少更新。 但是在Linux机器或VM上自己构建最新版本很容易 git clone https://github.com/openjdk/loom cd loom git checkout fibers sh configure make images 根据已安装的内容 configure可能会出现一些故障但是消息会告诉您需要安装哪些软件包以便继续进行。 在API的当前版本中光纤或现在称为虚拟线程的虚拟线程表示为Thread类的对象。 这是三种生产纤维的方法。 首先有一个新的工厂方法可以构造OS线程或虚拟线程 Thread thread Thread.newThread(taskname, Thread.VIRTUAL, runnable); 如果您需要更多自定义则有一个构建器API Thread thread Thread.builder().name(taskname).virtual().priority(Thread.MAX_PRIORITY).task(runnable).build(); 但是一段时间以来手动创建线程一直被认为是较差的做法因此您可能不应执行任何一种操作。 而是将执行程序与线程工厂一起使用 ThreadFactory factory Thread.builder().virtual().factory(); ExecutorService exec Executors.newFixedThreadPool(NTASKS, factory); 现在熟悉的固定线程池将以与以往相同的方式从工厂调度虚拟线程。 当然还将有OS级别的载体线程来运行这些虚拟线程但这是虚拟线程实现的内部。 固定线程池将限制并发虚拟线程的总数。 默认情况下从虚拟线程到承载线程的映射是通过使用系统属性jdk.defaultScheduler.parallelism或默认情况下Runtime.getRuntime().availableProcessors()所给定数量的内核的jdk.defaultScheduler.parallelism池完成的。 您可以在线程工厂中提供自己的调度程序 factory Thread.builder().virtual().scheduler(myExecutor).factory(); 我不知道这是否是人们想要做的。 为什么载具线程多于核心 返回我们的执行人服务。 您可以在虚拟线程上执行任务就像在OS级线程上执行任务一样 for (int i 1; i NTASKS; i) {String taskname task- i;exec.submit(() - run(taskname)); } exec.shutdown(); exec.awaitTermination(delay, TimeUnit.MILLISECONDS); 作为一个简单的测试我们可以在每个任务中入睡。 public static int DELAY 10_000;public static void run(Object obj) {try {Thread.sleep((int) (DELAY * Math.random()));} catch (InterruptedException ex) {ex.printStackTrace();}System.out.println(obj);} 如果现在将NTASKS设置为1_000_000并在工厂生成器中.virtual() 则该程序将失败并显示内存不足错误。 一百万个OS级线程占用大量内存。 但是使用虚拟线程它可以工作。 至少它应该工作并且对我之前的Loom版本确实有效。 不幸的是在12月5日下载的构建中我得到了一个核心转储。 当我尝试使用Loom时这时有发生。 希望在您尝试此操作时可以解决此问题。 现在您可以尝试更复杂的事情了。 亨氏·卡布兹Heinz Kabutz最近为益智游戏提供了一个程序该程序可加载数千个Dilbert卡通图像。 对于每个日历日都有一个页面例如https://dilbert.com/strip/2011-06-05 。 程序读取这些页面在每个页面中找到卡通图像的URL然后加载每个图像。 这是一堆混乱的期货 有点像 CompletableFuture.completedFuture(getUrlForDate(date)).thenComposeAsync(this::readPage, executor).thenApply(this::getImageUrl).thenComposeAsync(this::readPage).thenAccept(this::process); 使用光纤代码更加清晰 exec.submit(() - { String page new String(readPage(getUrlForDate(date)));byte[] image readPage(getImageUrl(page));process(image); }); 当然每个对readPage的调用readPage块但是对于纤维我们不在乎。 尝试一下您关心的事情。 阅读大量的网页进行处理进行更多的阻塞读取并享受光纤阻塞便宜的事实。 结构化的一致性 Project Loom的最初动机是实现光纤但是今年早些时候该项目开始了针对结构化并发的实验性API。 在这篇强烈推荐的文章 从中拍摄以下图像中Nathaniel Smith提出了结构化的并发形式。 这是他的中心论点。 在新线程中启动任务实际上并不比使用GOTO编程好即有害 new Thread(runnable).start(); 当多个线程在没有协调的情况下运行时这将是意大利面条代码。 在1960年代结构化编程将goto替换为分支循环和函数 现在结构化并发的时机已经到来。 当启动并发任务时通过阅读程序文本我们应该知道它们何时完成。 这样我们可以控制任务使用的资源。 到2019年夏季Project Loom有了一个用于表达结构化并发的API。 不幸的是由于最近进行了统一线程和光纤API的实验该API目前处于混乱状态但是您可以通过http://jdk.java.net/loom/上的原型进行尝试。 在这里我们安排了许多任务 FiberScope scope FiberScope.open(); for (int i 0; i NTASKS; i) {scope.schedule(() - run(i)); } scope.close(); 调用scope.close()阻塞直到所有光纤完成。 请记住光纤阻塞不是问题。 一旦关闭示波器您就可以确定光纤已经完成。 FiberScope是可FiberScope的因此您可以使用try -with-resources语句 try (var scope FiberScope.open()) {... } 但是如果其中一项任务没有完成怎么办 您可以使用截止日期 Instant 或超时 Duration 创建范围 try (var scope FiberScope.open(Instant.now().plusSeconds(30))) {for (...)scope.schedule(...); } 截止期限/超时之前尚未完成的所有光纤都将被取消。 怎么样 继续阅读。 消除 取消一直是Java的痛苦。 按照惯例您可以通过中断线程来取消线程。 如果线程正在阻塞则阻塞操作以InterruptedException终止。 否则设置中断状态标志。 正确地进行检查是乏味的。 可以重置中断状态或者InterruptedException是已检查的异常这没有帮助。 java.util.concurrent中取消的处理一直不一致。 考虑ExecutorService.invokeAny 。 如果任何任务产生结果则其他任务将被取消。 但是CompletableFuture.anyOf允许所有任务运行完成即使其结果将被忽略。 2019年夏季的Project Loom API解决了取消问题。 在该版本中光纤具有cancel操作类似于interrupt 但是取消是不可撤销的。 如果当前光纤已被取消则静态Fiber.cancelled方法将返回true 。 当示波器超时时其光纤将被取消。 取消可以由FiberScope构造函数中的以下选项控制。 CANCEL_AT_CLOSE 关闭范围取消所有调度的光纤而不是阻塞 PROPAGATE_CANCEL 如果取消拥有光纤则任何新调度的光纤都会自动取消 IGNORE_CANCEL 无法取消预定的光纤 所有这些选项都未在顶层设置。 PROPAGATE_CANCEL和IGNORE_CANCEL选项是从父范围继承的。 如您所见有相当多的可调整性。 我们将不得不看到重新审视此问题时会发生什么。 对于结构化并发当示波器超时或被强制关闭时必须自动取消示波器中的所有光纤。 螺纹局部 让我感到惊讶的是Project Loom实现者的痛苦之一是ThreadLocal变量以及更深奥的东西-上下文类加载器AccessControlContext 。 我不知道有那么多东西骑在线程上。 如果您的数据结构不适合并发访问则有时可以在每个线程中使用一个实例。 经典示例是SimpleDateFormat 。 当然您可以继续构造新的格式化程序对象但这并不高效。 所以你想分享一个。 但是全球 public static final SimpleDateFormat dateFormat new SimpleDateFormat(yyyy-MM-dd); 将无法正常工作。 如果两个线程同时访问它则格式可能会混乱。 因此每个线程中有一个是有意义的 public static final ThreadLocalSimpleDateFormat dateFormat ThreadLocal.withInitial(() - new SimpleDateFormat(yyyy-MM-dd)); 要访问实际的格式化程序请致电 String dateStamp dateFormat.get().format(new Date()); 首次调用get时将调用构造函数中的lambda。 从那时起get方法返回属于当前线程的实例。 对于线程这是公认的做法。 但是当一百万个光纤存在时您真的想拥有一百万个实例吗 这对我来说不是问题因为使用线程安全的东西如java.time格式化程序似乎更容易。 但是Project Loom一直在考虑“范围本地”对象-那些FiberScope被重新激活了。 在线程与处理器数量一样多的情况下线程局部变量也已被用作处理器局部性的近似值。 可以实际模拟用户意图的API可以支持此功能。 项目状况 想要使用Project Loom的开发人员自然会沉迷于API如您所见该API尚未解决。 但是很多实施工作都处于幕后。 一个关键部分是在操作阻塞时使光纤停放。 已经完成了网络连接因此您可以在光纤内连接到网站数据库等。 当前不支持本地文件操作块时的停车。 实际上在JDK 11、12和13中已经重新实现了这些库这是对频繁发布实用程序的致敬。 目前尚不支持在监视器上进行阻塞 synchronized块和方法但最终需要这样做。 ReentrantLock现在可以了。 如果纤维以本机方法阻塞则将“固定”线程并且所有纤维都不会前进。 Project Loom对此无能为力。 Method.invoke需要更多工作才能得到支持。 有关调试和监视支持的工作正在进行中。 如前所述稳定性仍然是一个问题。 最重要的是性能还有一段路要走。 停放光纤不是免费的午餐。 每次都需要替换运行时堆栈的一部分。 在所有这些方面都取得了很大的进展所以让我们回顾一下开发人员关心的API。 现在是查看Project Loom并考虑如何使用它的好时机。 同一类代表线和纤维对您有价值吗 还是您希望将一些Thread行李搬走 您是否认同结构化并发的承诺 试一下Project Loom看看它如何与您的应用程序和框架一起工作并为无畏的开发团队提供反馈 翻译自: https://www.javacodegeeks.com/2019/12/project-loom.html织机原理