消息机制

一、Android系统为什么不允许在子线程中访问UI? 这是因为Android的UI控件并不是线程安全的,如果多线程中并发访问可能导致UI控件处于不可预期的状态. 那为什么系统不对UI控件的访问加上锁机制呢? 缺点有两个:首先,加上锁机制会让UI访问的逻辑变得复杂;其次锁机制会降低UI访问的效率,因为锁机制会阻塞某些线程的执行. 鉴于这两个缺点,最简单且高效的方法及时采用单线程模型来处理UI操作,对于开发者来说也不是很麻烦,只是需要通过Handler切换一下UI访问的执行线程即可. 来源： CSDN 作者： shiningdreamercaihua 链接： https://blog.csdn.net/shiningdreamercaihua/article/details/103551047

参考地址： https://www.cnblogs.com/ultranms/p/9585191.html 在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。那这些服务又到底是什么呢？我们为什么需要这样的服务？我们又为什么要使用Zookeeper来实现呢，使用Zookeeper有什么优势？接下来我会挨个介绍这些到底是什么，以及有哪些开源系统中使用了。 配置管理 在我们的应用中除了代码外，还有一些就是各种配置。比如数据库连接等。一般我们都是使用配置文件的方式，在代码中引入这些配置文件。但是当我们只有一种配置，只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多，有很多服务器都需要这个配置，而且还可能是动态的话使用配置文件就不是个好主意了。这个时候往往需要寻找一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更

分组： 所有消息都要发布到每个实例 一个组只收到一个消息 Spring Cloud的配置（yml）： spring.cloud.stream: bindings.input: destination: products group: productsGroup 重试（retries and deadlock queues）： 如果customer处理一个message失败了，这个消息会丢失或者被这个用户要求重发 如果到了重试次数，仍然失败，把消息放到死锁队列里 配置重试和死锁队列（rabbitMQ和KAFKA）： spring.cloud.stream.bindings.input.consumer: maxAttempts: 3 backOffInitialInterval: 500 backOffMaxInterval: 1000 backOffMultiplier: 2.0 spring.cloud.stream.rabbit.bindings.input.consumer: autoBindDlq: true republishToDlq: truespring.cloud.stream.kafka.bindings.input.consumer: enableDlq: true Partitions（分区） 配置了分区的话，消息有个关键字，关键字相同的消息

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> #0 系列目录# 聊聊远程通信 Java远程通讯技术及原理分析 聊聊Socket、TCP/IP、HTTP、FTP及网络编程 RMI原理及实现 RPC原理及实现 轻量级分布式 RPC 框架 使用 RMI + ZooKeeper 实现远程调用框架 深入浅出SOA思想 微服务、SOA 和 API对比与分析 聊聊同步、异步、阻塞与非阻塞 聊聊Linux 五种IO模型 聊聊IO多路复用之select、poll、epoll详解 聊聊C10K问题及解决方案 近来遇到了一些常见的概念，尤其是网络编程方面的概念，如：阻塞、非阻塞、异步I/O等等，对于这些概念自己也没有太清晰的认识，只是很模糊的概念，说了解吧也了解，但是要让自己准确的描述概念方面的具体细节，却说的不那么准确，这也是自己在这几个方面也没有细细考究过的原因吧。经过看了些这几个概念的资料，发现同步、异步、阻塞、非阻塞的概念其实也并不难以理解，在此写下此文，欢迎拍砖，希望多多交流。 #1 同步与异步# 首先来解释同步和异步的概念，这两个概念与消息的通知机制有关。也就是同步与异步主要是从消息通知机制角度来说的。 ##1.1 概念描述## 所谓同步就是一个任务的完成需要依赖另外一个任务时，只有等待被依赖的任务完成后，依赖的任务才能算完成，这是一种可靠的任务序列

一，性能优化专题： 1.tomcat性能调优 怎么给tomcat调优 如何加大comcat连接数 怎么加大tomcat的内存 tomcat中如何禁止列目录下的文件 Tomcat有几种部署方式 tomcat的优化经验 2.jvm性能优化专题： Java类加载过程 java内存分配 描述一下jvm加载class文件的原理机制 GC是什么？为什么要有GC？ 简述java垃圾回收机制 如何判断一个对象是否存活？（或者GC对象的判定方法） 垃圾回收的优点和原理。并考虑2种回收机制。 垃圾回收器的基本原理是什么？垃圾回收器可以马上回收内存吗？ 有什么办法主动通知虚拟机进行垃圾回收？ java中会存在内存泄漏吗，请简单描述。 深拷贝和浅拷贝 syatem，gc**() 和runtime，gc ()**会做做什么事情？ finalize方法什么时候被调用？析构函数（finalizatinon）的目的是什么？ 如何对象的引用被置为null，垃圾收集器是否会立即释放对象占用的内存？ 什么是分布式垃圾回收（DGC）？它是如何工作的？ 串行（serial）收集器和吞吐量（throughout）收集器的区别是什么？ 在Java中，对象什么时候可以被垃圾回收？ 简述Java内存分配与回收策率以及minor GC和majorGC。 jvm的永久代中会发生垃圾回收吗？ Java中垃圾收集的方法有哪些？

本文将深入剖析rocketmq为什么选择自己开发NameServer，而不是选择类似于ZK这样的开源组件。同时对rocketmq的路由注册、路由发现、路由剔除进行剖析。并通过结合核心源码，对笔者的观点进行验证。同时对不同类型消息的重试机制，以及客户端选择nameserver的策略进行深入讲解。 文章第一部分是name server在rocketmq整体架构中的作用，熟悉的同学可以直接跳过。 1 NameServer的作用 Name Server 是专为 RocketMQ 设计的轻量级名称服务，具有简单、可集群横吐扩展、无状态，节点之间互不通信等特点。整个Rocketmq集群的工作原理如下图所示： 可以看到，Broker集群、Producer集群、Consumer集群都需要与NameServer集群进行通信： Broker集群 Broker用于接收生产者发送消息，或者消费者消费消息的请求。一个Broker集群由多组Master/Slave组成，Master可写可读，Slave只可以读，Master将写入的数据同步给Slave。每个Broker节点，在启动时，都会遍历NameServer列表，与每个NameServer建立长连接，注册自己的信息，之后定时上报。 Producer集群 消息的生产者，通过NameServer集群获得Topic的路由信息，包括Topic下面有哪些Queue

在Objective-C中，message与方法的真正实现是在执行阶段绑定的，而非编译阶段。编译器会将消息发送转换成对objc_msgSend方法的调用。 objc_msgSend方法含两个必要参数：receiver、方法名（即：selector），如： [receiver message]; 将被转换为： objc_msgSend(receiver, selector); objc_msgSend方法也能hold住message的参数，如： objc_msgSend(receiver, selector, arg1, arg2, …); objc_msgSend方法会做按照顺序进行以下操作，以完成动态绑定： 查找selector所指代的程序（方法的真正实现）。因为不同类对同一方法有不同的实现，所以对方法的真正实现的查找依赖于receiver的类 调用该实现，并将一系列参数传递过去 将该实现的返回值作为自己的返回值，返回之 消息传递的关键是，编译器构建每个类和对象时所采用的数据结构。每个类都包含以下两个必要元素： 一个指向父类的指针 一个调度表（dispatch table）。该调度表将类的selector与方法的实际内存地址关联起来 每个对象都有一个指向所属类的指针 isa 。通过该指针，对象可以找到它所属的类，也就找到了其全部父类，如下图所示： 当向一个对象发送消息时，objc

版权声明：本文由史燕飞原创文章，转载请注明出处: 文章原文链接： https://www.qcloud.com/community/article/82 来源：腾云阁 https://www.qcloud.com/community RFC2616发布以来，一直是互联网发展的基石。HTTP协议也成为了可以在任何领域使用的核心协议，基于这个协议人们设计和部署了越来越多的应用。HTTP的简单本质是其快速发展的关键，但随着越来越多的应用被部署到WEB上，HTTP的问题慢慢凸显出来。今天，用户和开发者都迫切需要通过THHP1.1达到一种几近实时的响应速度和协议性能，而要满足这个需求，只在原有协议上进行修补是不够的。为了应对这些挑战，HTTP必须继续发展。HTTP工作组已经在2012年宣布要设计和开发HTTP2.0。HTTP2.0的主要目标是改进传输性能，实现低延迟和高吞吐量。 在HTTP2.0真正诞生之前，谷歌开发了一个实验性质的协议-SPDY，它定位于解决HTTP1.1中的一些性能限制，来减少网页的延时。自从2009年SPDY发布之后，这个协议得到了众多浏览器厂商和大型网站的支持，实践证明它确实可以很大幅度的提升性能，已经具备成为一个标准的条件。于是，HTTP-WG于2012年初提出要重在SPDY的一些实践基础上新设计和开发HTTP2.0，以期使数据传输具有更好的性能和更少的延时

主要是记录下iOS的界面触摸事件处理机制,然后用一个实例来说明下应用场景. 一、处理机制 界面响应消息机制分两块，（1）首先在视图的层次结构里找到能响应消息的那个视图。（2）然后在找到的视图里处理消息。 【关键】（1）的过程是从父View到子View查找，而（2）是从找到的那个子View往父View回溯（不一定会往回传递消息）。 1.1、寻找响应消息视图的过程可以借用M了个J的一张图来说明。 处理原理如下： • 当用户点击屏幕时，会产生一个触摸事件，系统会将该事件加入到一个由UIApplication管理的事件队列中 • UIApplication会从事件队列中取出最前面的事件进行分发以便处理，通常，先发送事件给应用程序的主窗口(UIWindow) • 主窗口会调用hitTest:withEvent:方法在视图(UIView)层次结构中找到一个最合适的UIView来处理触摸事件 (hitTest:withEvent:其实是UIView的一个方法，UIWindow继承自UIView，因此主窗口UIWindow也是属于视图的一种) • hitTest:withEvent:方法大致处理流程是这样的： 首先调用 当前视图 的pointInside:withEvent:方法判断触摸点是否在 当前视图 内： ▶ 若pointInside:withEvent:方法返回NO，说明触摸点 不在

应用场景 　　(1)同一应用具有多个进程的不同组件之间的消息通信 　　　　　a)不同应用间的组件之间的消息通信 　　　　　b)与Android系统在特定情况下的通信,如：系统开机，网络变化等 　　(2)同一应用内同一组件的消息通信：显然扩展变量的作用域、接口回调、Handler-Message等方式都能更简单的实现。 　　(3)同一应用内的不同组件之间的消息通信(单个进程)：对于简单的的情况，依靠接口的回调方式就可解决；而较为复杂的情况，更推荐直接使用EventBus等。 （2）、（3）场景理论上可以使用，但是实际开发没有人这么做。 实现原理 设计模式与模型: Android中的广播使用了观察者模式， 模型为 基于消息的发布/订阅事件模型。 从设计模式上讲，广播的发送者和接收者极大程度的解耦，使得系统方便集成，容易扩展 模型成员： 消息发布者(广播发布者) 消息订阅者(广播接收者) 消息中心(AMS，Activity Manager Service，一个Android系统中极其重要！的成分，以后我们会详细讲解) 此处我们扩展一下，观察者模式和发布订阅模式的关系 发布订阅模式属于广义上的观察者模式 ,前者时最常用的一种观察者模式的实现，且从解耦和重用角度上看更优于典型的观察者模式， 在观察者模式中，观察者需要直接订阅目标事件，在目标发出内容改变的事件后，直接接收事件并作出响应。