算法：动态规划解法及例题

算法：动态规划解法及例题经历过很多算法题，其中最常见的解题方法便是动态规划 动态规划（dynamic programming,即DP)，是一种常见的求解最优解的方案，他通过将复杂的问题拆分为单阶段的小问题求解，核心思想是递推，通过简单基础的解一步步接近最优解 对于一个算法问题，总有一个相对令人满意的解，但却不一定是我们想要的最优解，譬如在解决动态规划中最经典的背包问题时，有些人首先想到简单省心的贪心算法，取价值最高或是性价比最高的物品组合，这种方案得到的很有可能是最优解，但贪心的算法并不适用于动态规划领域，若是物品中恰好有能将背包塞得很满的组合，而采用贪心策略却浪费了很多背包空间 其实贪心策略本身更多也是一种“相对最优”的解决方案，而很少是真正的最优，这一点请务必斟酌
2020-03-11鱼鱼

mysql orderby排序

mysql orderby排序where 字段和orderby字段组成一个联合索引，这个样一个普通业务的order只需要通过这个索引就能确定排序顺序，不需要额外的临时表来计算字段的排序 可以通过配置max_length_for_sort_data改变mysql判断采取方式 全字段排序 将命中的行的所有要查询的结果集都放到排序的临时表内，排序后将数据结果集返回 rowid 排序 将命中的行的排序字段和主键id放到临时表内排序，再根据排序后的主键id进行一次回表查询 虽然有联合索引，但是当where的条件不止一个时候，order by就会失效，可以采取多次查询结果，然后在服务中排序的方式来解决问题
2020-05-17yangwcn

待办事宜

待办事宜2018-10-18 解决XSS攻击问题（v-html） 针对缺省有所设置(blog:page等) 添加新增按钮 添加置顶 解决日志编辑首行出现空格 开发射线：一个匿名交流板 留言 联系方式 可回复 筑楼 时限性 超时关闭 匿名 默认匿名 字典： 可标注，添加富文本新组件字典（视情况添加 工作量难以预估 可考量在全网） 字典包括 可见性（待定），条目，解释，相关词条 必须可编辑 添加不同风格 参照http://www.unconstraint.cn/，github两种风格可切换 流动 简约 重金属 使用图床存储较大的图片（RECOMMEND：使用新浪微博）
2019-03-24鱼鱼

Spring MVC源码和设计思想1 DispatcherServlet

Spring MVC源码和设计思想1 DispatcherServlet此篇文章是个人通过阅览Spring MVC源码的学习过程记录，包含Spring MVC的关键细节源码设计和一些设计上的tips，更近似于一种意识流的记录方式，锚点设置可能也有些乱，零零散散的点我日后有时间会统一总结起来 Restful风格的Http有八种请求方式，除了最常使用的Get与Post还有Head、Put、Delete、Options、Trace、Connect 在Restful接口的设计中，请求方方式的语义性很强，我们时常用他约束接口请求的行为，请求类型的语义： OPTIONS获取服务器支持的HTTP请求方法； HEAD跟get很像，但是不返回响应体信息，用于检查对象是否存在，并获取包含在响应消息头中的信息
2019-06-03鱼鱼

Kafka服务端集群原理

Kafka服务端集群原理kafka是家喻户晓的消息队列，也因“纯粹”而闻名（高性能高吞吐、扩展较少较为简单），此篇文章整理Kafka的基本架构，将按照Kafka的版本迭代分别展示架构的演进（截至版本3.0） 我们在这里暂且只讨论Kafka服务端，对于生产者和消费者的逻辑简单带过 扫盲一下Kafka的部分概念： Producer mq生产者通用叫法 作为消息的生产者，在生产完消息后需要将消息投送到指定的目的地（某个topic的某个partition） Producer可以根据指定选择partition的算法或者是随机方式来选择发布消息到哪个partition； Consumer mq生产者通用叫法 消息消费者，向Kafka broker读取消息的客户端;，负责订阅和消费消息
2022-03-10鱼鱼

IO多路复用模型：select、poll、epoll对比

IO多路复用模型：select、poll、epoll对比我们平时提到的I/O几乎都是同步 阻塞模型，譬如网络请求的socket IO，在数据返回前，相应的线程或是进程将会一直 阻塞直到数据返回，比较直接的处理便是针对IO流一对一的监听，但在IO返回前，相应的系统资源会平白无故的浪费，这种处理方式会大大降低服务器的吞吐 如果我们用很少的线程来监听这些IO，就能实现对系统资源的更好利用，在相应的socket有数据返回时才去读取数据 这种方式被称作IO多路复用，在Linux系统中，实现IO多路复用的方式（从古老到新）有select、poll和epoll 现在很多中间件都使用epoll IO多路复用模型才因此有着很高的性能和吞吐 此处简单描述三种方式的实现和区别
2020-08-11鱼鱼

Redis原理-源码解析：数据结构1 字符串操作&SDS及预分配的实现验证

Redis原理-源码解析：数据结构1 字符串操作&SDS及预分配的实现验证所有原理实现基于Redis版本6.0.9 SDS(Simple Dynamic String)简单动态字符串，是Redis中字符串所采取的数据结构，SDS并不是Redis的独创，只是被Redis采纳的一种数据结构，用以替换C语言原生的字符串类型：sds仓库传送门 使用方法与原生的C语言字符串类似，并能提供很多类似的API SDS经过了两个版本，目前的解析大都基于v1 v1版本的sds数据结构很简单： 比起C语言中单一的字符数组构成的字符串，sds具有以下优势： 存储了字符串长度，相比C语言遍历获取长度，将时间复杂度由O(n)变为O(1); 当SDS每次发生修改时，会为其分配冗余空间，在字符串空间小于1MB时，每次分配实际长度2倍的空间，而在大于1MB时则是分配多1MB的空间，是在空间不足时才会触发分配
2020-11-16鱼鱼

算法：深度优先搜索（DFS）

算法：深度优先搜索（DFS）在算法：广度优先搜索（BFS）（最短路径）中，我们提到了按照广度优先遍历的搜索方式，使用队列作为常规的搜索方式，与之相对应的为深度优先搜索（DFS） 如果说BFS对应着树结构的前中后序遍历 但是DFS相对解法较为多元一些，有些时候不得不使用递归进行求解 同时，有很多求解只是进行图的遍历，不关心是广度还是深度优先，其解都是相同的 在这里我们暂且不讨论的基于栈而是侧重基于递归的遍历实现 对于二叉树，最常见的遍历方式有前序(又称 先序)遍历、中序遍历、后序遍历、层次遍历 前中后序只为取得的值先后顺序不同，即递归有先后 依赖栈实现的的深度优先是前序遍历 以下是一个二叉树的前序遍历代码实现：
2020-06-27鱼鱼

tips

tips一些小tip： 向上转型，失去特征 定义相同对象，重写hash和（不是或）equal Vue.nextTick() 回调函数：在Vue（重新）渲染页面之后调用 vue绑定样式，我们会发现background-color 不能直接绑定 需写为backgroundColor 因为js中不允许出现‘-’ 存库之前，mysql会把换行符什么的过滤掉，使得出入不一致（应用场景：textarea存）解决：this.value.replace(/\n|\r\n/g,"
") linux下的mysql的表名是区分大小写的！ 实现线程接口 Runnable 注解注入失败 注解注入失败 Linux下缺少部分字体，使用drawString会出问题(二维码模块)，解决手段：从windows引入字体，因为不是什么主流问题所以就简单写一下，如果再碰到相关问题在详细的讲述一下
2019-05-08鱼鱼

多线程应用提高(III) 并发编程的艺术

多线程应用提高(III) 并发编程的艺术《并发编程的艺术》p36：JMM不保证64位的long型和double型变量的写操作具有原子性 面试中可能经常会被问到HashMap和HashTable的区别，其中最重要的就是前者并不是线程安全的，但其实在高并发的情形下，后者的效率低的不像话甚至不可用，所以在jdk7之后出现了线程高效且安全的ConcurrentHashMap 当并发严重时，某线程若是调用了同步方法，另外的线程将进入阻塞/轮询状态，既不能put也不能get，但ConcurrentHashMap是不同的，它采用了锁的分段技术，将数据分段存储，不同的数据持有不同的锁，这样可用性会大大高于HashTable，所以在实际开发中我们都用ConcurrentHashMap取代HashTable
2019-06-18鱼鱼

Consul API文档

Consul API文档这是一个记录Consul 常用API的文档，因为Consul的跨语言性，所以http API在Consul中尤为重要，此文档基于Consul版本1.6.0的v1 API，有其他的变化请参阅Consul官方API文档 Consul API采用经典的rest图谱Consul API版本只有一个版本，所以所有的前缀都为 /v1/，返回值以Json格式传输，可以添加pretty参数格式化Json，以本地部署为例，整体的baseUrl为127.0.0.1:8500/v1/ 获取代理成员列表和基本信息，类似于指令'consul members' 开启维护模式后，该代理节点将会被标注为不可用，可以用于上线前临时屏蔽node的服务
2019-12-01鱼鱼

MySQL tips

MySQL tips一些日常接触到的MySQL优化tips，比较散乱 假设有一个用户表，对于一句很简单的查询语句： 假设name与age字段均有单列索引，容易想到的是，MySQL应该会分别走两次索引，并将其结合起来，EXPLAIN也是如此，大多数时候MySQL会进行优化，我们可能会看到EXPLAIN的结果中有Using union或Using soft union，这是MySQL针对OR做了隐性的优化，但当SQL复杂或数据极端情况下，这一语句极容易变成全表扫描，偶尔使用联合索引可能解决问题，更多情况则是MySQL“昏了头”，即使OR条件均涉及数据条数不多，依旧没能在查询语句中使用索引，此时应调整为UNION语句(可以权衡一下重复及顺序是否有影响，可以使用更快的UNION ALL)：
2021-01-13鱼鱼

网站地图

首页 博客 {{screen}} 第 {{page}} 页

{{blog.title}}

{{blog.content}}

{{blog.createDate}} ◔ {{blog.timeline}} {{blog.author}} {{tag}}

{{blog.likeCount}}{{blog.commentCount}}

分类下暂时没有文章哦！

主题分类

源码解析

造个轮子吧

多线程应用提高

问题探究

来做几道算法题

微服务架构实战

QuickStart

电子出版物

Java排坑指南

做点有趣的！

瞧瞧看看MySQL

{{taggroup.label}} 

{{tag.value}}