游乐园的名称为：Canobie Lake Park 中午时段人太多，每个游戏项目大约要排队等候20-30分钟。 所有的项目都已经在门票里面，所以并不需要单独进行购票，唯一不太好的就是一些热门的项目排队时间很长，比如说过山车。 这个过山车是全木结构的过山车，有一定的高度，但是还没有到让人疯狂的程度吧。 这滑板车看着上去都晕。 上面和下面的这游乐场滑板车的照片基本上都是在游乐场的最末端了。 上面都可以看到是接近黄昏了，哪怕就是这个时候，人还是蛮多的。 https://www.isharkfly.com/t/canobie-lake-park/14883
如你在看 JDK 的源代码的时候，大概率会看到很多方法使用了 native 关键字。 下面是 String 对象 JDK 中的源代码，就带有了一个 native 关键字。 native 是干什么用的 简单来说就是 Java 的 native 方法的实现不是用 Java 实现的，可能在其他语言里面。 一个 Native Method 就是一个 java 调用非 java 代码的接口。 一个Native Method是这样一个java的方法：该方法是一个原生态方法，方法对应的实现不是在当前文件，而是在用其他语言（如C和C++）实现的文件中。 使用 native 关键字说明这个方法是原生函数，也就是这个方法是用C/C++语言实现的，并且被编译成了DLL，由java去调用。 JVM 中很多的底层实现都是使用 C 实现的。 看看 openj9 的源代码就知道了。 例如下图上面 openj9 中的 gc，就是 C 实现的。 JDK 在调用上面一些实现的时候，显然是调用了外部的动态库等，所以我们用 native 在这里标记下，表示具体实现在 JVM 里面。 实现 具体的实现是通过 JNI 实现的。 JNI 的全称为 Java Native Interface，一句话来说就是Java的本地接口，和我们常见的很多Java方法，很多实现是由Java本身来实现的，有的时候还需要本地方法来提供相关的功能。 通过 JNI 就可以实现调用了。 在这里 native 只是在 JDK 里面标记下。 https://www.isharkfly.com/t/java-native/14878
C-130大力神（Hercules，海格力斯，希腊神话中的英雄）运输机是由美国洛克希德马丁公司（Lockheed Martin）所研发生产的中型战术运输机，是美国从1956年开始服役，总生产量高达2,000架以上的现役运输机，在美国战术空运力量中占有核心的地位，同时也是美战略空运中重要的辅助力量。 C-130配备四个涡轮螺旋桨发动机，可以在未准备跑道上起降。最初被设计用来输送武装力量、医疗救援、货物转运。 后来演化出各种用途，包括空中打击、搜索救援、科学研究、气象观测、空中加油、海岸巡逻、空中救火。现在是许多国家的重要空军战术运输机，目前有40多个型号在60多个国家服役。 C-130 主打的就是一个皮实，对跑道要求不高，能够在未铺装的简易跑道上起降，易维护，起飞不怕低空扬尘空气颗粒密度大。 这次展出的是 C-130 雪橇，还真行，给飞机轮子上装个雪橇就能够在雪地上降落了。 飞机的尾号是 21094，应该多次执行过雪地任务了。 这次也拿过来遛了下。 在蜜月期，我们也进口过基架 C-130，后因缺少相应的配件就转卖给其他国家了。 从实用水平上来说 C-130 确实是一个比较解释耐用的飞机，在美国这机器就是干糙活用的，感觉从军队到国民警卫队，到海岸警卫队都有在飞。 https://www.isharkfly.com/t/c-130/14880
说是题目可以用不同的语言，但是貌似 Java 是多线程的，用 Java 写肯定容易不少。 但，觉得这个题目用多线程简直是有点脱了裤子放屁。 完整题目内容 题目的网站内容如下： Please complete the following challenge in one of the following programming languages: C, C++, C#, Java, Python, Go, or Typescript. Please only use standard or ubiquitous libraries. If you heavily rely on a library, please include a description on how that library call works with as much detail as possible. Busy Body Bank services many in-person customers every day in their large luxurious lobby at the center of a city. They have N Tellers in stalls at any time to accommodate heavy traffic while optimizing for employee hours whenever possible. N changes from day-to-day as the bank’s management anticipates surges or reductions of Customer count. When the bank is empty, tellers are asleep. When a Customer enters, they announce themselves and a teller wakes up and conducts a transaction that takes some amount of time. As more customers arrive, they wake Tellers and conduct a transaction or wait in the bank’s queue for a teller to become available (if there are none immediately available). The bank’s queue line has M possible positions where Customers can wait for tellers to become available. If a Customer walks into the bank to find no available tellers and a full queue, they will take their business to Small and Simple, a bank across the street. If the bank gets more customers than it expects on any day, then it will call more Tellers in to accommodate this surge, but calling Tellers on-demand usually costs the bank more money than the lost business from under-staffing. The bank…
因最近需要在本地调试消息策略。 如果搞个服务器装就太辛苦了，所以就想到了 NAS，我们的 NAS 上已经装了 Docker，我们直接运行一个 Activemq Artemis 的镜像不就好了。 下载镜像 在进入 NAS 的容器管理后，访问 Registry。 然后输入 activeMq 进行查找。 选择已经找到的镜像，然后单击页面上部的下载按钮。 选择最新版本。 直接单击应用就好。 我们可以看到在界面中，提示进行正在下载，在这里根据你网络的情况可能需要点时间。 创建容器 然后单击容器部分，在这里创建一个容器。 选择我们已经下载的镜像来进行创建。 其他的使用默认选项就好。 端口映射 在这个界面中，需要对端口进行映射。 因为不同的消息协议会使用不同的端口，JMS 多使用的是 61616 端口。 管理管理的界面为 8161 端口。 在这里，为了方便，直接全部映射上去就好。 然后下一步继续，等待 NAS 帮我们把容器创建好。 过一段时间，如果能够看到容器运行了，那么我们就可以访问消息服务器的界面了。 上图显示创建的容器已经在运行了。 第一次创建的时间会比较长，主要观察下日志。 只有你看到下面的日志出现后，消息服务器才会显示已经正常运行了。 如上面的日志还没有输出到这里的话，控制台界面是访问不了的。 从我们的运行来看，第一次创建我们，NAS 花了差不多 3 分多钟的时间才完成。 访问消息服务器 ActiveMQ Artemis 的管理界面使用的端口是 8161。 直接访问上面的地址。 使用的登录用户名和密码是在你创建容器的时候默认输入的，如果你没有改过，用户名密码都为：artemis 上图就显示的是当前正在运行的消息服务器。 这个时候，你的代码应该可以连上这个消息服务器，并且进行消息的收发了。 https://www.isharkfly.com/t/synology-nas-docker-activemq-artemis/14879
最近在搞 ActiveMQ 的时候，发现有 2 个 ActiveMQ 可以下载。 应该下那个呢？ JMS 即Java Message Service，是JavaEE的消息服务接口。 JMS主要有两个版本：1.1和2.0。 2.0和1.1相比，主要是简化了收发消息的代码。 所谓消息服务，就是两个进程之间，通过消息服务器传递消息。 实际上ActiveMQ Classic原来就叫ActiveMQ，是Apache开发的基于JMS 1.1的消息服务器，目前稳定版本号是5.x，而 ActiveMQ Artemis 是 由RedHat捐赠的 HornetQ服 务器代码的基础上开发的，目前稳定版本号是 2.x。 和ActiveMQ Classic相比，Artemis版的代码与Classic完全不同，并且，它支持JMS 2.0，使用基于Netty的异步IO，大大提升了性能。 针对数据的持久层 ActiveMQ Artemis 还能够支持 JDBC。 总结 整体来说，ActiveMQ 通常指的是 ActiveMQ Classic，为了简化去掉了 Classic。 ActiveMQ Artemis 应该是作为下一个版本来候选的，支持的协议更新。 2 套 ActiveMQ 的代码是不一样的。 如果用不到什么太多的消息策略高级需求，可以就使用 ActiveMQ Classic 就好。 因为这 2 个消息服务器的代码完全不一样，导致如果你使用 Spring 的话，使用的包的代码也不一样，ActiveMQ artemis 的调用代码更加简单，界面更好看。 如项目只是需要一个消息服务器，并且没有什么技术负担，使用 Spring 的框架的话，用 ActiveMQ artemis 可能更好些。 有谁不愿意看好看的界面呢？ https://www.isharkfly.com/t/activemq/14877/1
基于 Rabbitmq 官方的说明，现在 Rabbitmq 还没有办法完全的原生支持 AMQP 1.0。 官方的文章列表在：Which protocols does RabbitMQ support? — RabbitMQ 从上面的文章来看，感觉是 AMQP 1.0 的升级太大，只能通过插件的方式来进行兼容。 至于什么时候能够支持，貌似现在还没有时间表。 Spring 的 AMQP 项目就是针对 Rabbitmq 来写的。 https://www.isharkfly.com/t/rabbitmq-amqp-1-0/14876
有一种动物，它“蹄似牛而非牛，面似马而非马，尾似驴而非驴，角似鹿而非鹿”。别看它长的怪，但名声却很大，它就是传说中的“四不像”。 四不像”这种异兽是我国独有的品种，传说当年封神的姜子牙，他的坐骑就是这种异兽。书中写道：“麟头豸尾体如龙，足踏祥云至九重。四海九州随意遍，三山五岳霎时逢。 ”怎么样，是不是觉得很厉害。 在北美这边，这种四不像的物种被称为 ELK，实在是没有搞清楚这个鹿是什么品种的鹿，应该是 麋鹿 吧。 但是看起来又不是非常像。 北美这边的各种奇奇怪怪的鹿，让人有点完全搞不清楚方向。 除了特别大的驼鹿（Moose）比较好认以外，其他都有点晕晕的感觉。 有没有。 https://www.isharkfly.com/t/elk/14871
Java消息服务（Java Message Service，简称JMS）是用于访问企业消息系统的开发商中立的API。企业消息系统可以协助应用软件通过网络进行消息交互。JMS在其中扮演的角色与JDBC很相似，正如JDBC提供了一套用于访问各种不同关系数据库的公共API，JMS也提供了独立于特定厂商的企业消息系统访问方式。 使用JMS的应用程序被称为JMS客户端，处理消息路由与传递的消息系统被称为JMS Provider，而JMS应用则是由多个JMS客户端和一个JMS Provider构成的业务系统。发送消息的JMS客户端被称为生产者（producer），而接收消息的JMS客户端则被称为消费者(consumer)。同一JMS客户端既可以是生产者也可以是消费者。 JMS的编程过程很简单，概括为：应用程序A发送一条消息到消息服务器（也就是JMS Provider）的某个目得地(Destination)，然后消息服务器把消息转发给应用程序B。因为应用程序A和应用程序B没有直接的代码关连，所以两者实现了解耦。 JMS 不是现在才有的概念，早在上个世纪 90 年代就已经有了。 JMS 1.0 JMS 1.0.1 (October 5, 1998) JMS 1.0.1a (October 30, 1998) JMS 1.0.2 (December 17, 1999) JMS 1.0.2a (December 23, 1999) JMS 1.0.2b (August 27, 2001) JMS 1.1 (April 12, 2002) JMS 2.0 (May 21, 2013) JMS 2.0a (March 16, 2015) JMS 主要是在 Java 世界中使用，但目前现在消息策略已经有了很大的变化。 不同语言直接也有消息发送和消费的请求，所以目前使用比较多的消息协议是 AMQP，这个就没有办法用 JMS 进行处理。 因此，Apache Active MQ 就在消息策略上面进行了包装，让 Active MQ 也能支持现代的 AMQP。 如果你的应用服务是 Java 的服务的话，使用 Active MQ 通常能够满足你的消息处理需求。 在客户端和服务器之间，我们可以使用上面的方法，让客户端发送一个消息到消息服务器上，当另外一个服务器收到消息请求后，就会对消息进行处理然后返回。 这个过程如果使用 JMS 是可以解耦的，我们直接定义接口就可以了。 有点像 Protocol Buffers，但 Protocol Buffers 是基于 http 的，我们也需要定义 Protocol Buffers 后进行编译部署后才可以用。 https://www.isharkfly.com/t/jms/14874
