javaweb简记-学习笔记

最新推荐文章于 2024-05-31 10:26:40 发布

PJ_boy

最新推荐文章于 2024-05-31 10:26:40 发布

阅读量179

点赞数

分类专栏： Java 文章标签：数据库 spring java mysql 多线程

本文链接：https://blog.csdn.net/PJ_boy/article/details/114883149

版权

Java 专栏收录该内容

19 篇文章 0 订阅

订阅专栏

Servlet

servlet生命周期流程

创建对象-->初始化-->service()-->doXXX()-->销毁

创建对象的实际

默认是第一次访问该Servlet的时候创建的
也可以通过配置web.xml，来改变创建的时机，比如在容器启动的时候去创建，DispatherServlet（StringMVC前端控制器）就是一个例子 <load-on-startup>1</load-on-startup>

创建对象的时机

对象的创建只有一次，单例
初始化一次
销毁一次

关于线程安全（构成线程不安全的三个因素）

多线程的环境（有多个客户端，同时访问servlet）
多线程共享资源，比如一个单例对象（servlet的单例的）
这个单例是有状态的（比如在servlet方法中采用全局变量，并且以该变量的运算结果作为下一步的操作的判断依据）

描述Session跟Cookie的区别

存储位置不同

Session：服务端
Cookie：客户端

存储格式不同

Session： value为对象，Object类型
Cookie：value为字符串，如果我们存储一个对象，这个时候就需要将对象转换为json

存储大小不同

Session存储受服务器内存限制
Cookie：一般来说，最大为4K

生命周期不同

Session：服务端控制，默认是30分钟，也可以通过web.xml自己设置session的过期时间。注意：当用户关闭浏览器，不能代表Session消失。
Cookie：客户端控制，其实是客户端的一个文件，分两种情况（（1）默认的是会话级别的cookie，这种随着浏览器的关闭而消失，比如保存的Session的cookie。（2）非会话级别cookie，通常设置有效期来控制，比如“七天免登录”这种功能，需要设置有效期，setMaxAge）
cookie的其他配置

httpOnly=true:防止客户端的xss攻击

path=‘/’:访问路径

domain=‘’：设置cookie的域名

cookie跟session之间的联系

http协议是一种无状态协议，服务器为了记住用户的状态，我们采用的是session的机制，而session机制背后的原理是，服务器会自动生成会话级别的cookie来保存session的标识。

转发和重定向的区别

1.转发

转发的作用范围是服务器内部，即发生在服务器内部的跳转，所以，对于客户端来说，始终都是一个请求，所以这个期间，保存在request域中的数据可以进行传递

2.重定向

发生在客户端的跳转，所以，是多次请求，这个时候，如果需要在多次请求之间传递，就需要session对象。

三层架构是那三层

web层（表现层）：负责与用户交互并对外提供服务接口（代表框架 SpringMVC、Struts1、Strut2）

MVC是对web层进一步的划分，有：

*Model（模型）-模型代表一个存取数据的对象或java domain（pojo）

*View（视图层）-视图代表模型包含数据的可视化比如HTML，jsp，thymeleaf

*Controller（控制层）控制器作用域模型和视图上，它控制数据流向模型对象，并在数据变化时更新视图，它使视图和模型分离开，目前的技术代表有Servlet，controller

业务逻辑层：实现业务逻辑模块（代表框架 Spring 、Springboot）

数据存取层：将业务逻辑层处理的结果进行持久化，方便后续查询（代表框架：Mybatis，jdbc）

jsp九大内置对象

request （HttpServletRequest）
response (HttpServletResponse)
config (ServletConfig)
application (ServletContext)
session (HttpSession)
exception(Throwable)
page(Object(this))
out (JspWriter)
pageContext (PageContext)

JSP四大域对象

四大域对象

ServletContext context域
HttpSession session域
HttpServletRequest request域
PageContext page

4大域对象的范围

page域：只能在当前jsp页面使用（当前页面）
request域：只能在同一个请求中使用（转发才有效，重定向无效）
session域：只能在同一个会话中有效。如一个用户登录的会话，知道该用户注销位置，所有页面共享session域数据
context：只能在同一个web应用中使用。(全局的)

数据库三大范式与反范式

1.数据库三大范式

第一范式：列不可分
第二范式：要有主键
第三范式：不可存在传递依赖（比如商品表里面关联商品类别表，那么只需要一个关键字product_type_id 即可，其他字段信息可以通过表关联查询即可得到，如果商品表还存在一个商品类别名称字段，如product_type_name，那就属于存在传递依赖的情况，第三范式主要是从空间的角度来考虑，避免产生冗余信息，浪费磁盘空间）

2.反范式设计：（第三范式）为什么会有反范式设计?

原因一：提高查询效率（读多少写多少）比如上述的描述中，显示商品信息时，经常需要伴随商品类别信息的展示，所以这个时候，为了提高查询效率，可以通过冗余一个商品字段名称，这个可以将原先的表关联查询变为单表查询
原因二：保存历史快照信息，比如订单表，里面需要包含收货人的各项信息，如姓名，电话，地址，等等，这些都属于历史快照，需要冗余保存起来。不能通过保存用户地址id去关联查询，因为用户的收货人信息可能会在后期发生改变等等。

如何解决SQL注入

1.SQL注入，是指通过字符串拼接的方式构成了一种特殊的查询语句

select * from t_user where username = '' and password = '' 'or 1=1 #
select * from t_user where username = '' or 1=1 # ' and password = ''

2.解决方案

采用预处理对象，采用PreparedStatement对象，而不是Statement对象。该对象不仅可以解决SQL注入问题，另外也可以执行效率，因为是预先编译执行的，SQL执行过程（语法校验--编译--执行）

3.延伸

Mybatis如何解决SQL注入问题？解决方案时采用 # 占位符而不是$占位符
mybatis的#和$差异就是#可以解决SQL注入问题，而后者不能

事务特点

1.原子性

事务是数据库的逻辑工作单位，事务中包含的各操作要么都完成，要么都不完成

2.一致性

事务一致性是指数据库中的数据在事务操作前后都必须满足业务规则约束，如a给b转账，数据必须能对得上

3.隔离性

一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰（设置不同的隔离级别，互相干扰的程度不同）

4.持久性

事务一旦提交，结果便是永久性，及时发送宕机，仍然可以依靠事务日志完成数据的持久化
日志包括回滚日志（undo）和重做日志（redo），当我们通过事务修改数据时，首先会将数据库变化的信息记录到重做日志中，然后再对数据库中的数据进行修改，这样即使数据库系统发送崩溃，我们还可以通过重做日志进行数据恢复。

事务隔离级别

READ UNCOMMITTED 读为提交在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别是最低的隔离级别，虽然拥有超高的并发处理能力及很低的系统开销，但很少用于实际应用。因为采用这种隔离级别只能防止第一类更新丢失问题，不能解决脏读，不可重复读及幻读问题。
READ COMMITTED 读已提交，这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别可以防止脏读问题，但会出现不可重复读及幻读问题。
REPEATABLE READ 可重复读，这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。这种隔离级别可以防止除幻读外的其他问题。
SERIALIZABLE 串行化，这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读、第二类更新丢失问题。在这个级别，可以解决上面提到的所有并发问题，但可能导致大量的超时现象和锁竞争，通常数据库不会用这个隔离级别，我们需要其他的机制来解决这些问题:乐观锁和悲观锁。

特别说明

幻读：B事务读取了两次数据，在这两次的读取过程中A事务添加了数据，B事务的这两次读取出来的集合不一样。
脏读：A事务执行过程中，B事务读取了A事务的修改。但是由于某些原因，A事务可能没有完成提交，发生RollBack了操作，则B事务所读取的数据就会是不正确的。这个未提交数据就是脏读（Dirty Read）。
不可重复读：B事务读取了两次数据，在这两次的读取过程中A事务修改了数据，B事务的这两次读取出来的数据不一样。B事务这种读取的结果，即为不可重复读

synchronized和lock区别

1.位置不同

lock 只能给代码块加锁
synchronized 可以给方法和代码块加锁

2.锁的获取锁和释放锁不同

synchronized 无需手动获取锁和释放锁，发生异常会自动解锁，不会出现死锁
lock需要自己加锁和释放锁，如lock和unlock，如果忘记unlock则会出现死锁，所以一般在finally里面使用unlock

3.注意

synchronized 修饰成员方法是默认的锁对象，，就是当前对象
synchronized修饰静态方法是，默认锁的对象就是类的class对象，如XXX.class
synchronized修饰代码块时，可以自己来设置锁对象

TCP和UDP的区别

1.相同点

都是传输层的协议

2.不同点

TCP提供可靠的传输协议，传输前需要建立连接，面向字节流传输慢（开始：三次挥手结束：四次握手）
UDP无法保证传输的可靠性，无需创建连接，以报文的形式传输，效率高

什么是死锁？如何防止死锁

1.什么是死锁

例子：转换到线程的场景，就是线程A持有独占锁资源a，并尝试获取独占锁资源b，同时线程B持有独占资源b,并尝试去独占锁资源a
如果预防死锁：尽量采用 try lock（timeout）的方法，可以设置超时时间，这样超时时间后，就自动释放资源，防止死锁。

package lock;



//死锁.
public class DeadLock {
    private static final Object a = new Object();
    private static final Object b = new Object();

    public static void main(String[] args) {
        new Thread(new Task(false)).start();
        new Thread(new Task(true)).start();
    }

    public static class Task implements Runnable{

        private boolean flage;

        public Task(boolean flage){
            this.flage = flage;
        }

        @Override
        public void run() {
            if (flage){
                synchronized (a){
                    System.out.println(Thread.currentThread().getName()+"获取a");
                    try {
                        Thread.sleep(2);

                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    synchronized (b){
                        System.out.println(Thread.currentThread().getName()+"获取b");
                    }
                }
            }else {
                synchronized (b){
                    System.out.println(Thread.currentThread().getName()+"获取b");
                    synchronized (a){
                        System.out.println(Thread.currentThread().getName()+"获取a");
                    }
                }
            }

        }
    }


}

降低锁的使用粒度，不要几个功能共用一把锁。

反射

1.反射就是把Java类中的各种成分映射成相应的java类

2.很多框架都是基于反射实现的，如spring等

package com.ye.reflect;

import java.lang.reflect.Field;
import java.lang.reflect.Method;

/**
 * @program: java_interview
 * @description:
 * @author: LLh - yeyeye
 * @create: 2021-03-17 08:49
 **/
public class Student {
    public static void main(String[] args) {
        //以class对象为基础，类中每一部分，都有对应的类与之匹配
        try {
            Class<?> aClass = Class.forName("com.ye.reflect.Reflect");
            System.out.println(aClass);
            //表示属性的类
            Field aClassField = aClass.getField("ss");
            System.out.println(aClassField);
            //获取公有方法  表示公有方法的类
            Method aClassMethod = aClass.getMethod("hello", String.class);
            //获取私有方法  表示私有方法的类
            Method declaredMethod = aClass.getDeclaredMethod("hello1", String.class);
            System.out.println(declaredMethod);
            System.out.println(aClassMethod);
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (NoSuchFieldException e) {
            e.printStackTrace();
        }
    }
}


package com.ye.reflect;

/**
 * @program: java_interview
 * @description:
 * @author: LLh - yeyeye
 * @create: 2021-03-17 08:49
 **/
public class Reflect {

    public String ss = "ss";

    public void hello(String name){
        System.out.println("hello");
    }
    private void hello1(String name){
        System.out.println("hello1");
    }
}

spring简单理解

1.IOC和AOP

核心的IOC容器技术（控制反转），帮助我们自动管理依赖的对象，不需要我们自己创建和管理依赖对象，从而实现了层与层之间的解耦，所以，重点是解耦
核心的aop技术（面向切面编程），方便我们将一下非核心业务逻辑抽离，从而实现核心业务和非核心业务的解耦，比如添加一个商品的信息，那么核心业务就是添加商品信息记录这个操作，非核心业务比如，事务管理，日志，性能检查，读写分离的实现等等。

2.spring的bean作用域有哪些：

默认是单例模式 singleton ，即单例模式
prototype，每次从容器调用bean是都会创建一个新的对象，比如整合Struts2框架的时候，spring管理的action对象就需要这么配置
request,每次http请求都会创建一个对象
session，同一个session共享一个对象
global-session

3.spring的bean是线程安全的吗？

首先构成线程不安全的又三个条件：多线程环境、访问同一个资源、资源具有状态性。
spring的bean基本是无状态的，所以是安全的，所谓的无状态就是没有存储数据，即没有通过数据的状态来作为下一步的操作的判断依据。

悲观锁与乐观锁（SQL）

悲观锁是利用数据库本身的锁机制来实现，会锁记录实现方式。
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

select * from t_table where id = 1 for update

乐观锁是一种不锁记录的实现方式，采用CAS模式，建议采用version字段来作为判断依据，每次对数据更新操作，都会对version+1，这样更新提交操作时，如果version的值已被更改，则更新失败。
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

update tproduct set store = store+1,version+1 where id = 1 and version = old_version

假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。当需要对账户信息表进行更新的时候，需要首先读取version字段。

操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。
在操作员 A 操作的过程中，操作员B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
操作员 A 完成了修改工作，提交更新之前会先看数据库的版本和自己读取到的版本是否一致，一致的话，就会将数据版本号加1（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
操作员 B 完成了操作，提交更新之前会先看数据库的版本和自己读取到的版本是否一致，但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，而自己读取到的版本号为1 ，不满足 “ 当前最后更新的version与操作员第一次读取的版本号相等 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。
这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。
使用场景：我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

PJ_boy

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
javaweb简记-学习笔记

Servletservlet生命周期流程创建对象-->初始化-->service()-->doXXX()-->销毁创建对象的实际默认是第一次访问该Servlet的时候创建的也可以通过配置web.xml，来改变创建的时机，比如在容器启动的时候去创建，DispatherServlet（StringMVC前端控制器）就是一个例子 <load-on-startup>1</load-on-startup> 创建对象的时机对象的创建只有一.
复制链接

扫一扫