Flask核心机制之上下文源码剖析

一、前言

了解过flask的python开发者想必都知道flask中核心机制莫过于上下文管理,当然学习flask如果不了解其中的处理流程,可能在很多问题上不能得到解决,当然我在写本篇文章之前也看到了很多博文有关于对flask上下文管理的剖析都非常到位,当然为了学习flask我也把对flask上下文理解写下来供自己参考,也希望对其他人有所帮助。

二、知识储备

threadlocal

在多线程中,线程间的数据是共享的, 但是每个线程想要有自己的数据该怎么实现? python中的threading.local对象已经实现,其原理是利用线程的唯一标识作为key,数据作为value来保存其自己的数据,以下是demo演示了多个线程同时修改同一变量的值的结果:

#!/usr/bin/env python3
# -*- coding:utf-8 -*-
# Author:wd

import threading
import time
values=threading.local()

def run(arg):
  values.num=arg #修改threading.local对象的name数据
  time.sleep(1)
  print(threading.current_thread().name,values.num) #打印values.num

for i in range(3):
  th = threading.Thread(target=run, args=(i,), name='run thread%s' % i)
  th.start()

结果:
run thread0 0
run thread1 1
run thread2 2

结果说明:

从结果中可以看到,values.num的值是不同的,按照普通线程理解因为有sleep存在,在每个线程最后打印values.num时候值应该都是2,但是正是因为threading.local对象内部会为每个线程开辟一个内存空间,从而使得每个线程都有自己的单独数据,所以每个线程修改的是自己的数据(内部实现为字典),打印结果才不一样。

有了以上的设计思想,我们可以自己定义类似于thread.local类,为了支持协程,将其唯一标识改为协程的唯一标识,其实这已经及其接近flask中的Local类了(后续在进行说明):

try:
  from greenlet import getcurrent as get_ident # 携程唯一标识
except ImportError:
  try:
    from thread import get_ident
  except ImportError:
    from _thread import get_ident # 线程唯一标识

class Local(object):
  def __init__(self):
    object.__setattr__(self, 'storage', dict()) # 防止self.xxx 递归
    object.__setattr__(self, '__get_ident__', get_ident)

  def __setattr__(self, key, value):
    ident = self.__get_ident__() # 获取当前线程或协程的唯一标识
    data = self.storage.get(ident)
    if not data: # 当前线程没有数据
      data = {key: value} # 创建数据
    else: # 当前已经有数据
      data[key] = value

    self.storage[ident] = data # 最后为当前线程设置其标识对应的数据

  def __getattr__(self, name):
    try:
      return self.storage[self.__get_ident__()].get(name) # 返回name所对应的值
    except KeyError:
      raise AttributeError(name)

functools.partial

partial函数是工具包的一个不常用函数,其作用是给函数传递参数,同时返回的也是这个函数,但是这个函数的已经带了参数了,示例:

from functools import partial

def func(x,y,z):
  print(x,y,z)

new_fun=partial(func,1,2) #生成新的函数,该函数中已经有一个参数
new_fun(3)

结果:
1 2 3

在以上示例中,new_func是由func生成的,它已经参数1,2了,只需要传递3即可运行。

werkzeug

werkzeug是一个实现了wsgi协议的模块,用官方语言介绍:Werkzeug is a WSGI utility library for Python. It's widely used and BSD licensed。为什么会提到它呢,这是因为flask内部使用的wsgi模块就是werkzeug,以下是一个示例(如果你了解wsgi协议的应该不用过多介绍):

from werkzeug.wrappers import Request, Response

@Request.application
def application(request):
  return Response('Hello World!')

if __name__ == '__main__':
  from werkzeug.serving import run_simple
  run_simple('localhost', 4000, application)

在示例中application是一个可调用的对象也可以是带有__call__方法的对象,在run_simple内部执行application(),也就是在源码的execute(self.server.app)中执行,这里你只需要run_simple会执行第三个参数加括号。

三、源码剖析

上下文管理

在说请求上下文之前先看一个flask的hell world示例:

from flask import Flask

app=Flask(__name__)
@app.route("/")
def hello():
  return 'hello world'

if __name__=='__main__':
  app.run()

在以上示例中,app.run是请求的入口,而app是Flask实例化的对象,所以执行的是Flask类中的run方法,而在该改方法中又执行了run_simple方法,以下是run方法部分源码摘抄(其中self就是app对象):

from werkzeug.serving import run_simple

try:
  run_simple(host, port, self, **options)
finally:
  # reset the first request information if the development server
  # reset normally. This makes it possible to restart the server
  # without reloader and that stuff from an interactive shell.
  self._got_first_request = False

在run_simple中会执行app(environ, start_response),参考werkzeug的源码,源码会执行app(environ, start_response)也就是执行app的__call__方法,以下是__call__方法源码摘抄:

def __call__(self, environ, start_response):
  """The WSGI server calls the Flask application object as the
  WSGI application. This calls :meth:`wsgi_app` which can be
  wrapped to applying middleware."""
  return self.wsgi_app(environ, start_response)

__call__方法中又调用了wsgi_app方法,该方法也就是flask的核心所在,下面是方法摘抄:

def wsgi_app(self, environ, start_response):
  """The actual WSGI application. This is not implemented in
  :meth:`__call__` so that middlewares can be applied without
  losing a reference to the app object. Instead of doing this::

    app = MyMiddleware(app)

  It's a better idea to do this instead::

    app.wsgi_app = MyMiddleware(app.wsgi_app)

  Then you still have the original application object around and
  can continue to call methods on it.

  .. versionchanged:: 0.7
    Teardown events for the request and app contexts are called
    even if an unhandled error occurs. Other events may not be
    called depending on when an error occurs during dispatch.
    See :ref:`callbacks-and-errors`.

  :param environ: A WSGI environment.
  :param start_response: A callable accepting a status code,
    a list of headers, and an optional exception context to
    start the response.
  """
  #ctx.app 当前app名称
  #ctx.request request对象,由app.request_class(environ)生成
  #ctx.session session 相关信息
  ctx = self.request_context(environ)
  error = None
  try:
    try:
      ctx.push()
      #push数据到local,此时push的数据分请求上线文和应用上下文
      # 将ctx通过Localstack添加到local中
      # app_ctx是APPContext对象
      response = self.full_dispatch_request()
    except Exception as e:
      error = e
      response = self.handle_exception(e)
    except:
      error = sys.exc_info()[1]
      raise
    return response(environ, start_response)
  finally:
    if self.should_ignore_error(error):
      error = None
    ctx.auto_pop(error)

第一句:ctx = self.request_context(environ)调用request_context实例化RequestContext对象,以下是RequestContext类的构造方法:

def __init__(self, app, environ, request=None):
  self.app = app
  if request is None:
    request = app.request_class(environ)
  self.request = request
  self.url_adapter = app.create_url_adapter(self.request)
  self.flashes = None
  self.session = None

此时的request为None,所以self.request=app.request_class(environ),而在Flask类中request_class = Request,此时执行的是Request(environ),也就是实例化Request类,用于封装请求数据,最后返回RequestContext对象,此时的ctx含有以下属性ctx.app(app对象)、ctx.request(请求封装的所有请求信息)、ctx.app(当前app对象)等

第二句:ctx.push(), 调用RequestContext的push方法,以下是源码摘抄:

def push(self):
  """Binds the request context to the current context."""
  # If an exception occurs in debug mode or if context preservation is
  # activated under exception situations exactly one context stays
  # on the stack. The rationale is that you want to access that
  # information under debug situations. However if someone forgets to
  # pop that context again we want to make sure that on the next push
  # it's invalidated, otherwise we run at risk that something leaks
  # memory. This is usually only a problem in test suite since this
  # functionality is not active in production environments.
  top = _request_ctx_stack.top
  if top is not None and top.preserved:
    top.pop(top._preserved_exc)

  # Before we push the request context we have to ensure that there
  # is an application context.
  app_ctx = _app_ctx_stack.top #获取应用上线文,一开始为none
  if app_ctx is None or app_ctx.app != self.app:
    # 创建APPContext(self)对象,app_ctx=APPContext(self)
    # 包含app_ctx.app ,当前app对象
    # 包含app_ctx.g , g可以看作是一个字典用来保存一个请求周期需要保存的值
    app_ctx = self.app.app_context()
    app_ctx.push()
    self._implicit_app_ctx_stack.append(app_ctx)
  else:
    self._implicit_app_ctx_stack.append(None)

  if hasattr(sys, 'exc_clear'):
    sys.exc_clear()
  #self 是RequestContext对象,其中包含了请求相关的所有数据
  _request_ctx_stack.push(self)

  # Open the session at the moment that the request context is available.
  # This allows a custom open_session method to use the request context.
  # Only open a new session if this is the first time the request was
  # pushed, otherwise stream_with_context loses the session.
  if self.session is None:
    session_interface = self.app.session_interface # 获取session信息
    self.session = session_interface.open_session(
      self.app, self.request
    )

    if self.session is None:
      self.session = session_interface.make_null_session(self.app)

到了这里可以看到,相关注解已经标注,flask内部将上下文分为了app_ctx(应用上下文)和_request_ctx(请求上下文),并分别用来两个LocalStack()来存放各自的数据(以下会用request_ctx说明,当然app_ctx也一样),其中app_ctx包含app、url_adapter一下是app_ctx构造方法:

def __init__(self, app):
  self.app = app
  self.url_adapter = app.create_url_adapter(None)
  self.g = app.app_ctx_globals_class()

  # Like request context, app contexts can be pushed multiple times
  # but there a basic "refcount" is enough to track them.
  self._refcnt = 0

然后分别执行app_ctx.push()方法和_request_ctx_stack.push(self)方法,将数据push到stack上,_request_ctx_stack.push(self),而_request_ctx_stack是一个LocalStack对象,是一个全局对象,具体路径在flask.globals,以下是其push方法:

def push(self, obj):
  """Pushes a new item to the stack"""
  #找_local对象中是否有stack,没有设置rv和_local.stack都为[]
  rv = getattr(self._local, 'stack', None)
  if rv is None:
    self._local.stack = rv = []
    # 执行Local对象的__setattr__方法,等价于a=[],rv=a, self._local.stack =a
    #创建字典,类似于storage={'唯一标识':{'stack':[]}}
  rv.append(obj)
    #列表中追加请求相关所有数据也就是storage={'唯一标识':{'stack':[RequestContext对象,]}}
  return rv

以上代码中的self._local是一个Local()对象源码定义如下,也就是用于存储每次请求的数据,和我们刚开始定义的local及其相似,这也是为什么要先提及下threadlocal。

Local()

class Local(object):
  __slots__ = ('__storage__', '__ident_func__')

  def __init__(self):
    object.__setattr__(self, '__storage__', {})
    object.__setattr__(self, '__ident_func__', get_ident)

  def __iter__(self):
    return iter(self.__storage__.items())

  def __call__(self, proxy):
    """Create a proxy for a name."""
    return LocalProxy(self, proxy)

  def __release_local__(self):
    self.__storage__.pop(self.__ident_func__(), None)

  def __getattr__(self, name):
    try:
      return self.__storage__[self.__ident_func__()][name]
    except KeyError:
      raise AttributeError(name)

  def __setattr__(self, name, value):
    ident = self.__ident_func__()
    storage = self.__storage__
    try:
      storage[ident][name] = value
    except KeyError:
      storage[ident] = {name: value}

  def __delattr__(self, name):
    try:
      del self.__storage__[self.__ident_func__()][name]
    except KeyError:
      raise AttributeError(name)

Local()

到这里我们知道了,当执行ctx.push()时,local对象中已经有数据了,接着开始执行self.full_dispatch_request(),也就是开始执行视图函数,以下是源码摘抄:

def full_dispatch_request(self):
  """Dispatches the request and on top of that performs request
  pre and postprocessing as well as HTTP exception catching and
  error handling.

  .. versionadded:: 0.7
  """
  self.try_trigger_before_first_request_functions()
  try:
    request_started.send(self)
    rv = self.preprocess_request()
    if rv is None:
      rv = self.dispatch_request()
  except Exception as e:
    rv = self.handle_user_exception(e)
  return self.finalize_request(rv)

在改方法中调用self.preprocess_request(),用于执行所有被before_request装饰器装饰的函数,从源码总可以看到如果该函数有返回,则不会执行self.dispatch_request()也就是视图函数,

执行完毕之后调用self.dispatch_request()根据路由匹配执行视图函数,然后响应最后调用ctx.auto_pop(error)将stack中的数据删除,此时完成一次请求。

全局对象request、g、session

在了解完flask的上下文管理时候,我们在视图函数中使用的request实际上是一个全局变量对象,当然还有g、session这里以request为例子,它是一个LocalProxy对象,以下是源码片段:

request = LocalProxy(partial(_lookup_req_object, 'request'))

当我们使用request.path时候实际上是调用是其__getattr__方法即LocalProxy对象的__getattr__方法,我们先来看看LocalProxy对象实例化的参数:

def __init__(self, local, name=None):
  #local是传入的函数,该句等价于self.__local=local,_类名__字段强行设置私有字段值
  #如果是requst则函数就是partial(_lookup_req_object, 'request')
  object.__setattr__(self, '_LocalProxy__local', local)
  object.__setattr__(self, '__name__', name) #开始的时候设置__name__的值为None
  if callable(local) and not hasattr(local, '__release_local__'):
    # "local" is a callable that is not an instance of Local or
    # LocalManager: mark it as a wrapped function.
    object.__setattr__(self, '__wrapped__', local)

在源码中实例化时候传递的是partial(_lookup_req_object, 'request')函数作为参数,也就是self.__local=该函数,partial参数也就是我们之前提到的partial函数,作用是传递参数,此时为_lookup_req_object函数传递request参数,这个在看看其__getattr__方法:

def __getattr__(self, name):
  #以获取request.method 为例子,此时name=method
  if name == '__members__':
    return dir(self._get_current_object())
  #self._get_current_object()返回的是ctx.request,再从ctx.request获取method (ctx.request.method)
  return getattr(self._get_current_object(), name)

在以上方法中会调用self._get_current_object()方法,而_get_current_object()方法中会调用self.__local()也就是带参数request参数的 _lookup_req_object方法从而返回ctx.request(请求上下文),最后通过然后反射获取name属性的值,这里我们name属性是path,如果是request.method name属性就是method,最后我们在看看_lookup_req_object怎么获取到的ctx.request,以下是源码摘抄:

def _lookup_req_object(name):
  #以name=request为列
  top = _request_ctx_stack.top
  # top是就是RequestContext(ctx)对象,里面含有request、session 等
  if top is None:
    raise RuntimeError(_request_ctx_err_msg)
  return getattr(top, name) #到RequestContext(ctx)中获取那么为request的值

在源码中很简单无非就是利用_request_ctx_stack(也就是LocalStack对象)的top属性返回stack中的ctx,在通过反射获取request,最后返回ctx.request。以上是整个flask的上下文核心机制,与其相似的全局对象有如下(session、g):

# context locals
_request_ctx_stack = LocalStack() #LocalStack()包含pop、push方法以及Local对象,上下文通过该对象push和pop
_app_ctx_stack = LocalStack()
current_app = LocalProxy(_find_app)
request = LocalProxy(partial(_lookup_req_object, 'request')) #reuqest是LocalProxy的对象,设置和获取request对象中的属性通过LocalProxy定义的各种双下划线实现
session = LocalProxy(partial(_lookup_req_object, 'session'))
g = LocalProxy(partial(_lookup_app_object, 'g')) 

技巧应用

利用flask的上下文处理机制我们获取上请求信息还可以使用如下方式:

from flask import Flask,_request_ctx_stack

app=Flask(__name__)

@app.route("/")
def hello():
  print(_request_ctx_stack.top.request.method) #结果GET,等价于request.method
  return 'this is wd'

if __name__=='__main__':
  app.run()

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • python框架flask表单实现详解

    这篇文章主要介绍了python框架flask表单实现详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下 表单 表单用于注册,修改用户数据等场景. flask-wtf提供了一个包,可以创建表单:pip install flask-wtf 为了防止跨域请求,flask_wtf自己生成一个秘钥,用秘钥生成加密口令,然后用口令验证表单中的数据真伪(是否被篡改过) from flask import Flask from flask import req

  • flask框架自定义过滤器示例【markdown文件读取和展示功能】

    本文实例讲述了flask框架自定义过滤器.分享给大家供大家参考,具体如下: 除了一些内置的join length safe等过滤器外, flask还提供了自定义过滤器的功能. 一. 自定义一个mardown过滤器 自定义一个markdown过滤器, 使过滤器可以像safe解析html标签一样解析md语法. 安装库 pip install Markdown==2.3.1 自定义过滤器 使用@app.template_filter('md')过滤器, 此时便拥有了名为md的过滤器. @app.tem

  • Flask框架路由和视图用法实例分析

    本文实例讲述了Flask框架路由和视图用法.分享给大家供大家参考,具体如下: 创建一个简单flask框架程序 #1.导入Flask类 from flask import Flask #2.创建Flask对象接收一个参数__name__,它会指向程序所在的包 app = Flask(__name__) #3.装饰器的作用是将路由映射到视图函数index @app.route('/') def index(): return 'Hello World' #4.Flask应用程序实例的run方法,启动

  • Flask之请求钩子的实现

    请求钩子 通过装饰器为一个模块添加请求钩子, 对当前模块的请求进行额外的处理. 比如权限验证. 说白了,就是在执行视图函数前后你可以进行一些处理,Flask使用装饰器为我们提供了注册通用函数的功能. 1.before_first_request:在处理第一个请求前执行 before_first_request 在对应用程序实例的第一个请求之前注册要运行的函数, 只会执行一次 #: A lists of functions that should be called at the beginnin

  • Flask框架中request、请求钩子、上下文用法分析

    本文实例讲述了Flask框架中request.请求钩子.上下文用法.分享给大家供大家参考,具体如下: request 就是flask中代表当前请求的request对象: 常用的属性如下: 属性 说明 类型 data 记录请求的数据,并转换为字符串 * form 记录请求中的表单数据 MultiDict args 记录请求中的查询参数 MultiDict cookies 记录请求中的cookie信息 Dict headers 记录请求中的报文头 EnvironHeaders method 记录请求

  • flask 实现token机制的示例代码

    token 的生成 用token校验身份,是前后端交互的常用方式. 它有以下特性: 会失效 加密 可以根据它拿到用户的信息 生成方式( 内部配置的私钥+有效期+用户的id ) #导入依赖包 from flask import request,jsonify,current_app from itsdangerous import TimedJSONWebSignatureSerializer as Serializer def create_token(api_user): ''' 生成toke

  • flask中过滤器的使用详解

    过滤器 过滤器的本质就是函数.有时候我们不仅仅只是需要输出变量的值,我们还需要修改变量的显示,甚至格式化.运算等等,而在模板中是不能直接调用 Python 中的某些方法,那么这就用到了过滤器. 使用方式: 过滤器的使用方式为:变量名 | 过滤器. {{variable | filter_name(*args)}} 如果没有任何参数传给过滤器,则可以把括号省略掉, flask中过滤器支持链式调用 {{variable | filter_name}} 常见内建过滤器 字符串操作 safe:禁用转义 

  • Flask框架请求钩子与request请求对象用法实例分析

    本文实例讲述了Flask框架请求钩子与request请求对象.分享给大家供大家参考,具体如下: 请求钩子 在客户端和服务器交互的过程中,有些准备工作或扫尾工作需要处理,比如: 在请求开始时,建立数据库连接 在请求开始时,根据需求进行权限校验 在请求结束时,指定数据的交互格式 为了让每个视图函数避免编写重复功能的代码,Flask提供了通用设施的功能,即请求钩子. 请求钩子是通过装饰器的形式实现,Flask支持如下四种请求钩子: 请求钩子 描述 before_first_request 在处理第一个

  • Flask框架钩子函数功能与用法分析

    本文实例讲述了Flask框架钩子函数功能与用法.分享给大家供大家参考,具体如下: 在Flask中钩子函数是使用特定的装饰器的函数.为什么叫做钩子函数呢,是因为钩子函数可以在正常执行的代码中,插入一段自己想要执行的代码,那么这种函数就叫做钩子函数. before_first_request:Flask项目第一次部署后会执行的钩子函数. before_request:请求已经到达了Flask,但是还没有进入到具体的视图函数之前调用.一般这个就是在函数之前,我们可以把一些后面需要用到的数据先处理好,方

  • Flask核心机制之上下文源码剖析

    一.前言 了解过flask的python开发者想必都知道flask中核心机制莫过于上下文管理,当然学习flask如果不了解其中的处理流程,可能在很多问题上不能得到解决,当然我在写本篇文章之前也看到了很多博文有关于对flask上下文管理的剖析都非常到位,当然为了学习flask我也把对flask上下文理解写下来供自己参考,也希望对其他人有所帮助. 二.知识储备 threadlocal 在多线程中,线程间的数据是共享的, 但是每个线程想要有自己的数据该怎么实现? python中的threading.l

  • python源码剖析之PyObject详解

    一.Python中的对象 Python中一切皆是对象. ----Guido van Rossum(1989) 这句话只要你学过python,你就很有可能在你的Python学习之旅的前30分钟就已经见过了,但是这句话具体是什么意思呢? 一句话来说,就是面向对象中的"类"和"对象"在Python中都是对象.类似于int对象的类型对象,实现了"类的概念",对类型对象"实例化"得到的实例对象实现了"对象"这个概念.

  • SpringBoot源码剖析之属性文件加载原理

    目录 前言 1.找到入口 2.ConfigFileApplicationListener 2.1 主要流程分析 2.2 Loader构造器 2.3 properties加载 总结 前言 首先我们来看一个问题.就是我们在创建SpringBoot项目的时候会在对应的application.properties或者application.yml文件中添加对应的属性信息,我们的问题是这些属性文件是什么时候被加载的?如果要实现自定义的属性文件怎么来实现呢?本文来给大家揭晓答案: 1.找到入口 结合我们前面

  • golang高并发系统限流策略漏桶和令牌桶算法源码剖析

    目录 前言 漏桶算法 样例 源码实现 令牌桶算法 样例 源码剖析 Limit类型 Limiter结构体 Reservation结构体 Limiter消费token limiter归还Token 总结 前言 今天与大家聊一聊高并发系统中的限流技术,限流又称为流量控制,是指限制到达系统的并发请求数,当达到限制条件则可以拒绝请求,可以起到保护下游服务,防止服务过载等作用.常用的限流策略有漏桶算法.令牌桶算法.滑动窗口:下文主要与大家一起分析一下漏桶算法和令牌桶算法,滑动窗口就不在这里这介绍了.好啦,废

  • 微前端框架qiankun源码剖析之下篇

    目录 引言 四.沙箱隔离 4.1 JS隔离 1. Snapshot沙箱 2. Legacy沙箱 3. Proxy沙箱 4.2 CSS隔离 1. ShadowDOM 2. Scoped CSS 五.通信方式 六.结语 引言 承接上文  微前端框架qiankun源码剖析之上篇 注意: 受篇幅限制,本文中所粘贴的代码都是经过作者删减梳理后的,只为讲述qiankun框架原理而展示,并非完整源码.如果需要阅读相关源码可以自行打开文中链接. 四.沙箱隔离 在基于single-spa开发的微前端应用中,子应用

  • 由浅入深讲解Javascript继承机制与simple-inheritance源码分析

    老生常谈的问题,大部分人也不一定可以系统的理解.Javascript语言对继承实现的并不好,需要工程师自己去实现一套完整的继承机制.下面我们由浅入深的系统掌握使用javascript继承的技巧. 1. 直接使用原型链 这是最简粗暴的一种方式,基本没法用于具体的项目中.一个简单的demo如下: function SuperType(){ this.property = true; } SuperType.prototype.getSuperValue = function(){ return th

  • 谈谈jQuery之Deferred源码剖析

    一.前言 大约在夏季,我们谈过ES6的Promise,其实在ES6前jQuery早就有了Promise,也就是我们所知道的Deferred对象,宗旨当然也和ES6的Promise一样,通过链式调用,避免层层嵌套,如下: //jquery版本大于1.8 function runAsync(){ var def = $.Deferred(); setTimeout(function(){ console.log('I am done'); def.resolve('whatever'); }, 10

  • 详解java实践SPI机制及浅析源码

    1.概念 正式步入今天的核心内容之前,溪源先给大家介绍一下关于SPI机制的相关概念,最后会提供实践源代码. SPI即Service Provider Interface,属于JDK内置的一种动态的服务提供发现机制,可以理解为运行时动态加载接口的实现类.更甚至,大家可以将SPI机制与设计模式中的策略模式建立联系. SPI机制: 从上图中理解SPI机制:标准化接口+策略模式+配置文件: SPI机制核心思想:系统设计的各个抽象,往往有很多不同的实现方案,在面向的对象的设计里,一般推荐模块之间基于接口编

  • JAVA核心知识之ConcurrentHashMap源码分析

    1 前言 ConcurrentHashMap是基于Hash表的Map接口实现,键与值均不允许为NULL,他是一个线程安全的Map.同时他也是一个无序的Map,不同时间进行遍历可能会得到不同的顺序.在JDK1.8之前,ConcurrentHashMap使用分段锁以在保证线程安全的同时获得更大的效率.JDK1.8开始舍弃了分段锁,使用自旋+CAS+sync关键字来实现同步.本文所述便是基于JDK1.8. ConcurrentHashMap与HashMap有共同之处,一些HashMap的基本概念与实现

  • Java并发编程之ReentrantLock实现原理及源码剖析

    目录 一.ReentrantLock简介 二.ReentrantLock使用 三.ReentrantLock源码分析 1.非公平锁源码分析 2.公平锁源码分析 前面<Java并发编程之JUC并发核心AQS同步队列原理剖析>介绍了AQS的同步等待队列的实现原理及源码分析,这节我们将介绍一下基于AQS实现的ReentranLock的应用.特性.实现原理及源码分析. 一.ReentrantLock简介 ReentrantLock位于Java的juc包里面,从JDK1.5开始出现,是基于AQS同步队列

随机推荐