weixin_43741322的博客

泛型可以在编译时发现类型不匹配的错误，避免在运行时出现类型转换异常。这可以提高代码的可靠性和稳定性。：使用泛型可以编写更通用的代码，可以处理各种类型的数据而不必每次都进行类型转换。通过编写泛型方法或泛型类，可以实现更灵活、更通用的编程。：使用泛型可以使代码更易读、易懂。在使用泛型的代码中，可以清晰地看到数据的类型，这有助于其他开发人员理解代码并进行维护。：泛型能够在编译时进行类型检查和擦除，避免了运行时的类型转换，从而提高程序的性能。

我们通常会开发一个监测功能，能够检测每台服务器的状态，并且能够知道某个进程的状态，如果它宕机了，我能能直接在页面就重启服务重启进程，不需要再找到运维人员去线下机房重启服务，或者远程重启服务，这样很麻烦。我觉得这个功能还是挺常用的，再我们实际企业应用中，肯定都是多台服务器同时部署使用的，这其中就会有一些服务器是数据服务器、接口服务器、专用服务器、或者其他系统的服务器等等。这就是我们启动和关闭的进程程序。url就是这个进程对应的具体位置，可以直接右键打开位置，然后把路径拷贝过来就行了。很简单，直接上代码吧。

当我们开发好一个Java应用时，再部署到服务器时，最简单的方法是直接java -jar xxx.jar 。但是这样非常的不优雅，后台必须一直保留着一个控制台黑色窗口，很不爽，总可能被别人误关，而且最重要的是如果服务器重启了， 还要手动去再启动Java程序，很麻烦。然而把Java程序注册成Windows服务就完美解决了这些问题。

今天更新这篇文章，是公司别的部门找我帮忙实现的一个功能。我一开始一听简单的一b，就连个数据库么， 我java开发工程师什么语言不会，都一个吊样。结果这个活， 干了好几天，哈哈，当然这期间大部分的时间不是写代码，是调试平台，我司有一个自己的自动化平台，我只想对这个平台说：你星星个星星星。简单介绍一下这两个东西。VBS 的全称是 Visual Basic Scripting Edition。

社交登录流程（第三方登录）

线程池执行流程

Redis 基本操作， 数据一致性的相关问题及解决方式

Session 的使用

单点登录简单流程分析

是众多中的一种。为什么使用？这就不得不说一下的作用了。1、异步异步， 其实也就类似多线程一样，在我们实际开发中最经常使用的场景就是，我们可能处理完成一个业务，想要发邮件的方式来通知用户。又因为这个发邮件只是通知用户，对实际的业务又没有任何影响，所以我们就可以把发邮件的部分使用的这种异步方式实现，缩短了程序的应时间。异步，缩短了响应时间。

用户下单调用订单服务，我们直接把这个消息发给MQ的订单交换机，同时调用远程库存服务锁定库存。：发给订单交换机的消息自动转发给死信队列，死信队列经过30分钟后过期会自动转发给我们另一个普通的队列。：跟第二步的同时，调用了库存服务的锁库存方法后，库存服务也会给库存交换机发一条消息，交换机转发给死信队列，经过60分钟后过期再转发给另一个普通队列。

结合我上一章总结的RabbitMQ的基本知识，其中的主要消息传递出现在下图三个节点，所以我们要做好消息的可靠投递就要保证这结果地方的信息不能丢失。实战1、在我们写代码之前我们首先要创建好我们自己的交换机、队列、绑定关系。然后才能进行消息的发送和接受。这几项的设置最简单的方式可以在我们的RabbitMQ的可视化界面直接操作，也可以在Java代码中设置。

幂等性问题，通俗讲就是用户对一个接口进行反复调用而引起数据错误问题。当然这个问题不一定是用户多次点击所导致，也可能是网络延迟等等多种原因所导致。尤其在我们开发的模块涉及到钱的时候，幂等性就非常重要。实现幂等性也有很多方法。其实我们最常使用到的就是为了实现幂等性。这些都是比较常见的，简单的。肯定也不是我今天想要记录的。（我们就拿最熟悉的电商下单页面来讲）因为我们的服务都是分布式集群架构的，所有这里在高并发下就存在这问题。在redis的查询和删除的空隙时间肯定还会有请求进来导致出问题。

首先，RabbitMQ的三大问题：消息丢失、消息重复、消息积压这三个问题中最严重的就是消息丢失的问题。那我我们就来反向介绍一下这几个问题的最简单处理办法。

通俗讲：我们是一条船上的人。没错这就是事务。人就是操作，船就是事务容器。不管有多少人，只要这些人都上了这条船，那么他们统一就是一个事务，即：他们可能同时抵达岸边，也可能同时翻船沉海，也可能同时又回到出发点，就是他们所有人的状态是一样的。事务的四大特性：1、原子性： 就是这整个事务是一个整体不可分割，就想上面举的例子这一条船就是一个事务，不能在分割。一个事务中的所有操作都是统一的，要么成功要么失败。就像船要么到达岸边，要么翻船。每个事务之间互不影响，就像船一样，两个船之间没有任何关系。

核心思想就是使用Redis中的信号量来控制减库存，完成快速秒杀。这样一个最简单的高并发下单减库存逻辑就完成了。看一下我本机测试的结果：我本机秒杀一次，秒杀接口的处理速度是7ms， 我们把中间的网管转发，网络传输时间再加上，一次秒杀的请求大约可以是15ms，那么我们单个tomcat至少能够支持1000线程的并发，那么我自己这台电脑现在1秒钟能够支持的并发就达到了1*1000ms/15ms*1000 = 6.666万。所以如果想要达到百万并发，我们可以提升服务器硬件质量或者集群部署就能轻松达到。