Servlet线程模型与异步请求

Servlet线程模型与异步请求本篇文章主要意在整理Servlet的线程模型,帮助大家更好的理解请求在广泛使用的web容器下(基于Servlet的Tomcat服务器)的运行原理 Servlet是Java的服务端框架,可以利用Servlet来编写一个动态服务器(动态主要是区别于单纯的html构建的静态页面),主要基于Http协议 通过Servlet提供的API,我们可以轻松的处理网络请求和与其他服务建立连接(相比于基于Socket编程),并且基于Java使得它具有跨平台性、灵活性 简单的说Servlet就是一个封装了操作网络请求的API,它将Http网络请求简化为更容易处理的对象 从某种意义上讲,当我们不适用任何web框架(例如Spring mvc和Struts2)时,我们编写的每一个页面(jsp或是继承于HttpServlet的类)也都可以说是一个Servlet
Servlet线程模型与异步请求2020-03-23鱼鱼

Spring源码解析(3) IoC容器配置读取和容器refresh

Spring源码解析(3) IoC容器配置读取和容器refresh在文章Spring源码解析(I) 基于SSM看Spring的使用和Spring启动监听中,讲述了web容器启动后会触发的方法实现中生成Context的部分,回顾下核心方法: 我们已经分析到了0.处,他对我们生成的容器做了一个判断,对于web.xml监听初始化的Context,其生成的WebApplicationContext都是ConfigurableWebApplicationContext的子类,所以必然会进入if分支 首先通过loadParentContext先加载了父容器,默认是null 然后调用了configureAndRefreshWebApplicationContext方法进行初始化和配置项的读取
Spring源码解析(3)  IoC容器配置读取和容器refresh2020-08-09鱼鱼

mysql前缀索引

mysql前缀索引有时候需要索引很长的字符列,这会让索引变得大且慢 通常可以索引开始的部分字符,这样可以大大节约索引空间,从而提高索引效率 但这样也会降低索引的选择性 前面已经说过,使用前缀索引,定义好长度,就可以做到既节省空间,又不用额外增加太多的查询成本 2.1因为前缀索引无法完全等于判断,只是前缀匹配,所以可能需要扫描的所以数会增加 2.2在特殊的查询里面 select id,email from SUser where email='zhangssxyz@xxx.com'; 前缀索引需要回到 id 索引再查一下,因为系统并不确定前缀索引的定义是否截断了完整信息 select count(distinct left(email,4))as L4,
mysql前缀索引2020-05-15yangwcn

网络时延、异步IO、Pipeline

网络时延、异步IO、Pipeline通过使用多线程是能提高网络延迟带来的负面效应的,也就是在IO密集型的应用中(尤其是网络IO密集应用中),通过异步操作或能显著提高性能,本篇讨论相关问题 并不是异步(多线程)定能提高性能,有这种讨论也是发现经常有人会滥用多线程 通常会有一种说法:如果想要采用多线程的来执行一段任务,为了提高性能,假设服务器中有N个核心,推荐在CPU密集型的应用中启用N个线程,而在IO密集型的任务中启用2*N个线程 本人不是很认同此种说法,他只能代表一个大致的度量,在实际应用中几乎可以说完全不准确,一般来说,权衡系统资源与性能后,前者可能需要更少的线程数,而后者根据实际情况也许适宜分配更多的线程数 这个概念大家一般都不是很陌生,在此再次科普下:所谓IO密集型任务,即是任务的资源消耗多集中在系统IO上,这里的IO本来包括磁盘IO和网络IO等,但是磁盘IO涉及文件句柄操作等系统限制不在本篇讨论,所以此篇文章所提主要指网络IO,高网络IO也是绝大多数web应用的特性
网络时延、异步IO、Pipeline2021-04-21鱼鱼

对多线程的执行效率探究——合理的任务并发拆分

对多线程的执行效率探究——合理的任务并发拆分通常,我们选择多线程执行任务有两个理由,一是复杂任务采用多线程处理能够在发生并发时让用户减少等待也能防止阻塞,一是充分利用空闲时间,提高任务处理的效率,就后者而言,此处探讨不考虑客户端并发是否有必要把一个任务拆分成多线程来处理 为了探究多线程的效率问题,我做了一个实验,将不同种类的任务分别用单线程和多线程执行,同时也试验了不同种类的锁机制 测试基于Java 8的版本,希望看到总结可以直接点击到文末 开启五个线程执行任务,设定了足够次数的循环输出,输出的数字和当前线程,利用System.currentTimeMillis()统计任务用时 (代码略)以下是相同任务在不同环境下执行多次的平均执行时间
对多线程的执行效率探究——合理的任务并发拆分2019-12-09鱼鱼

有关Session的碎碎念-ban掉cookie之后

有关Session的碎碎念-ban掉cookie之后java web中, 用session来表示用户浏览器(客户端)与服务器建立的一次会话 通常用sessionId来标记一个session,在Java中,有很简单的方式直接获取sessionId; 但是sessionId并不是session的特性,实际上,sessionId是在客户端首次创建会话时将生成的sessionId存入cookie中,在之后的访问中直接读取这个id值 当客户端禁止了cookie行为后,SessionId在每次刷新页面时都会更新,利用id来表示会话也成为了妄想,此篇文章意在说明,如何操作能使SessionId能够独立于cookie使用 这种操作其实在shiro中已经被应用了,当我们进入登录页面中,url后会出现";jssionid=xxxxxx",将sessionid显示的标注在url中,可以使用:
有关Session的碎碎念-ban掉cookie之后2019-03-08鱼鱼

MySQL杂记

MySQL杂记Explain 可以分析一个SELECT语句的性能,只要加在查询语句之前即可,会输出关于查询语句的分析,分析这个例子: id: SELECT 查询的标识符. 每个 SELECT 都会自动分配一个唯一的标识符. select_type: SELECT 查询的类型. table: 所查询的表 partitions: 匹配的分区 type: join 类型 possible_keys: 此次查询中可能选用的索引 key: 此次查询中确切使用到的索引. key_len: 索引长度占字节数 ref: 哪个字段或常数与 key 一起被使用 rows: 显示此查询一共扫描了多少行. 这个是一个估计值.
MySQL杂记2019-02-25鱼鱼

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):
MySQL tips2021-01-13鱼鱼

[Quick Start]RedisTemplate的bean手动配置

[Quick Start]RedisTemplate的bean手动配置 有时我们可能需要手动配置Redis的连接,例如动态修改或是从特殊的参数中获取,而不是使用SpringBoot的自有配置,此篇文章意在快速指引redis的手动配置 基于Spring项目和Jedis的底层,使用RedisTemplate; 通过Maven引入相关依赖,可以的话spring-data-redis选择2.0.0以上版本,较低版本需要的依赖: 如果使用了Spring-boot并且要使用较高的版本(例如在2.1.0后才有的某些API-putIfAbsent带有超时时间的版本),我们直接修改starter的版本是不够的,二者版本并不对称,我们需要去掉其中的redis依赖并单独引入 建议保持良好的依赖管理习惯,显式的移除依赖,而不是任其覆盖,如:
[Quick Start]RedisTemplate的bean手动配置 2020-02-24鱼鱼

数据库的存储过程、触发器和一些语法

数据库的存储过程、触发器和一些语法本篇文章讲述基于MySQL的存储过程触发器和一些相关的语法 在数据库中,存储过程是指将复用度很高并且不需要通过程序进行预编译的的SQL语句预先写好存放起来(此处所指的为用户定义在数据库中的存储过程),在需要时直接通过call调用 先看一个例子(注意,这不是创建存储过程的语句): 其中使用了日期相关的函数,DATE_SUB(CURDATE(),INTERCAL 10 DAY)代表当前时间前推十天 这个存储过程作用是查出十天前的数据然后将其删除 MySQL默认的分隔符是" ; ",这样一来定义存储过程就会因为 ; 被打断,所以在定义存储过程前后需要修改分隔符,使用DELIMITER关键字跟随分隔符,实际创建存储过程语句为:
数据库的存储过程、触发器和一些语法2019-06-12鱼鱼

数据库的瓶颈问题解决(主从分离)与多数据源切换

数据库的瓶颈问题解决(主从分离)与多数据源切换业务中,数据库的设计是极为重要的一环,在高并发的业务中,我们可以采用集群部署来缓解请求和逻辑处理的压力,但是在数据库的层面却不行,Oracle、Mysql等数据库的吞吐量很高,但是依旧有阈值,我们不能奢求单库能解决所有的问题,假设遇到了数据库的瓶颈问题,我们可以采用怎样的手段呢 想要数据库达到瓶颈(SQL执行效率明显变慢),其实是很困难的,我们在程序的设计中基本都会使用到数据库连接池控制数据连接,但当业务量提升之后,连接池若是经常达到饱和便容易产生阻塞,我们不得不开放更多的连接数,随之而来的便是数据库承载了更多的并发,解决问题的主要方式有三: 更细的划分业务逻辑,将高频业务表单独分离开来,并通过定期清理的方式减小查询的执行时间,将不同的数据库请求分发到不同服务器的不同库,可以一定程度下解决上文所述的问题,但是应以数据库的设计性为前提,绝对不能牺牲原有设计合理的数据结构将其进行拆分,得不偿失
数据库的瓶颈问题解决(主从分离)与多数据源切换2019-08-29鱼鱼

使用RPC与Restful接口调用服务

使用RPC与Restful接口调用服务在SOA和微服务架构中,远程通信是无法避免的,最常用的远程通信有两种方式: restful的接口,使用Http通信 使用dubbo或是Spring Cloud组件进行 RPC协议远程调用,可选地使用socket通信 不同的人对 RPC调用会有不同的看法,甚至对rpc本身的理解都不甚相同,但我认为 RPC有两种倾向: 一为语义化的 RPC 没有统一的请求规范,数据格式在开发人员中很难达成一致,在使用传统Http调用时,交互的双方需要约定一份“API文档”以保证数据格式的唯一性,这样API格式本身就成为了一道大墙,耽误研发双方的时间 但如果服务间采用语义化 RPC进行交互,双方可能并不需要一份文档,只要一份约定好的代码,并以此作为双方的依赖,在请求时也仅仅是直接调用方法本身,如此强的语义性怎能让人不爱
使用RPC与Restful接口调用服务2021-01-13鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}