文章摘要 两个栈1234567891011121314151617181920212223242526272829303132333435public int calculate(String s) { Deque<Integer> stack = new LinkedList<Integer>(); char preSign = '+'; int num = 0; int n = s.length(); for (int i = 0; i < n; ++i) { //判断这个字符是否是数字 if (Character.isDigit(s.charAt(i))) { //字符和字符的加减法都是用的对应的ASCII来进行的，由于字符对应的ASCII码也是按照数字的大小来的，所以直接就相当于字符直接相加减 num = num * 10 + s.charAt(i) - '0'; ...

从源码层面来详细了解 why为什么要使用线程池？ 线程过多会带来额外的开销，其中包括创建销毁线程的开销、调度线程的开销等等，同时也降低了计算机的整体性能。线程池维护多个线程，等待监督管理者分配可并发执行的任务。这种做法，一方面避免了处理任务时创建销毁线程开销的代价，另一方面避免了线程数量膨胀导致的过分调度问题，保证了对内核的充分利用。 what12345678910111213141516171819202122232425262728293031323334353637//ctl就是把线程的运行状态和工作线程数进行统一管理的//AtomicInteger这个类可以通过CAS达到无锁并发，效率比较高,这个变量有双重身份，它的高三位表示线程池的状态，低29位表示线程池中现有的线程数，这也是Doug Lea一个天才的设计，用最少的变量来减少锁竞争，提高并发效率。private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));///表示线程池线程数的bit数private static final int CO ...

文章摘要 SpringCloudNetFlix 核心问题微服务架构核心问题 服务很多，客户端如何访问 这么多服务，服务之间如何通信 如何治理服务 服务挂了怎么办 解决方案 Spring Cloud 生态 Spring Cloud NetFlix 一站式解决方案！ api网关：zuul组件 服务调用 Feign–HttpClinet http通信方式。同步 阻塞 服务注册发现 Eureka 熔断机制 Hystrix 负载均衡 ribbon Apache Dubbo Zookeeper 半自动，需要整合别人的 api：没有，用第三方插件，或者自己实现 Dubbo Zookeeper 没有，借助 Hystrix Spring Cloud Alibaba 最新的 一站式解决方案 更简单 认识Spring Cloudspringboot专注于快速、方便的开发单个个体微服务，springCloud关注全局协调的微服务框架 现在大型网站的架构图 Spring Cloud NetFlixEureka服务注册和服务发现 必须要进行参数优化，否则速度太慢 ...

文章摘要 保证消息不丢失生产者通过rabbitmq的一个confirm机制，消息发送到mq之后，将消息持久化到磁盘之后，才会返回confirm给生产者 消费者rabbitmq默认的是自动ack的机制，但是可能会发生消费者已经收到消息，但是还没有来得及处理消息就宕机的情况，这中情况下，会出现消息丢失的情况 自动ack的机制： 就是消费者只要接收到mq的消息，就会立即返回ack，不管消息是否已经处理完毕 所以采用手动ack机制来确保，消息处理完毕之后，才将ack发送给mq集群 高并发⾸先，⽤来临时存放未 ack 消息的存储需要承载⾼并发写⼊，⽽且我们不需要什么复杂的运算 操作，这种存储⾸选绝对不是 MySQL 之类的数据库，⽽建议采⽤ kv 存储。kv 存储承载⾼并发 能⼒极强，⽽且 kv 操作性能很⾼。 其次，投递消息之后等待 ack 的过程必须是异步的，也就是类似上⾯那样的代码，已经给出了 ⼀个初步的异步回调的⽅式。 消息投递出去之后，这个投递的线程其实就可以返回了，⾄于每个消息的异步回调，是通过在 channel 注册⼀个 confirm 监听器实现的。 收到⼀个消息 ack ...

简单介绍 session，cookie和token http什么是无状态呢？就是说这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。这种无状态的的好处是快速。坏处是假如我们想要把www.zhihu.com/login.html和www.zhihu.com/index.html关联起来，必须使用某些手段和工具 cookie和sessioncookie是session的一种实现方案 客户端访问服务器的流程如下： 首先，客户端会发送一个http请求到服务器端。 服务器端接受客户端请求后，建立一个session，并发送一个http响应到客户端，这个响应头，其中就包含Set-Cookie头部。该头部包含了sessionId。Set-Cookie格式如下，具体请看Cookie详解Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure] 在客户端发起的第二次请求，假如服务器给了set-Cookie，浏览器会自动在请求头中添加cookie 服务器接收请求，分解cookie，验证信息，核对成功后 ...

自动装配原理介绍 启动类注解众所周知，这是springboot的启动类的注解 12345678@SpringBootApplicationpublic class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); }} @SpringBootApplication12345678910@Target(ElementType.TYPE)@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@SpringBootConfiguration@EnableAutoConfiguration@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class ...

来源为什么需要分布式锁？ 主要是由于在单服务器系统我们常用本地锁来避免并发带来的问题，但是，当服务采用集群方式部署时，本地锁无法在多个服务器之间生效，这时候保证数据的一致性就需要分布式锁来实现。 特征一个相对安全的分布式锁具备什么特征？ 互斥性。互斥是锁的基本特征，同一时刻锁只能被一个线程持有，执行临界区操作。 超时释放。通过超时释放，可以避免死锁，防止不必要的线程等待和资源浪费，类似于 MySQL 的 InnoDB 引擎中的 innodblockwait_timeout 参数配置。 可重入性。一个线程在持有锁的情况可以对其再次请求加锁，防止锁在线程执行完临界区操作之前释放。 高性能和高可用。加锁和释放锁的过程性能开销要尽可能的低，同时也要保证高可用，防止分布式锁意外失效。 实现方式 Memcached 分布式锁 利用 Memcached 的 add 命令。此命令是原子性操作，只有在 key 不存在的情况下，才能 add 成功，也就意味着线程得到了锁。 Zookeeper 分布式锁 利用 Zookeeper 的顺序临时节点，来实现分布式锁和等待队列。ZooKeeper 作为一个专门 ...

深入理解spring注解的构成 自定义注解12public @interface zhujie {} 其实最简单注解就是这样的，直接使用@interface后面跟上你想自定义的注解的名字即可 当然了，有一些本身在注解上常用的注解，下面一一来介绍。 原生注解@target123456789101112@Documented@Retention(RetentionPolicy.RUNTIME)@Target(ElementType.ANNOTATION_TYPE)public @interface Target { /** * Returns an array of the kinds of elements an annotation type * can be applied to. * @return an array of the kinds of elements an annotation type * can be applied to */ ElementType[] value();& ...

详细对比hashCode和equals hashCode()和equals()是什么？hashCode()方法和equals()方法的作用其实一样，在Java里都是用来对比两个对象是否相等一致。 hashCode()和equals()区别是什么？性能就性能来说，肯定是hashcode更快一下，毕竟只需要比较hashcode值就好 equals的话，比如String类型，如果是字符串比较大的话，比较起来就比较慢，如果字符串比较小的话，就比较快 可靠性 equals()相等的两个对象他们的hashCode()肯定相等，也就是用equals()对比是绝对可靠的。 hashCode()相等的两个对象他们的equals()不一定相等，也就是hashCode()不是绝对可靠的。 为何重写equals也要重写hashcode如果你重写了equals，比如说是基于对象的内容实现的，而保留hashCode的实现不变，那么很可能某两个对象明明是“相等”，而hashCode却不一样。 这样，当你用其中的一个作为键保存到hashMap、hasoTable或hashSet中，再以“相等的”找另一个作为键 ...