轻量级

要实现企业应用集成，就不能不解决单点登录问题。单点登录（ SSO ， Single Sign On ） 也可称统一认证服务，就是用户只登录一次就可以访问多个应用系统而不需要重新登录。怎么解决单点登录问题，用任何一个搜索引擎，都可以找到各种解决方法，可谓是八仙过海、各显神通。本文的目的不是提供一个功能齐全、安全可靠的解决方法，而是提供一个只使用原始 Web 技术、与软件平台无关、与用户验证形式无关、只有用户验证功能、可以在安全性不过强求的情况下使用的方法——轻量级单点登录系统。虽然本文是使用 .NET 框架、 C# 实现的，但完全可以按照同样方法使用其它平台、其它语言来实现；虽然本文是使用用户名和密码写在代码中这种最烂的用户验证形式，但完全可以使用数据库、 Active Directory 等形式来验证用户。 很多单点登录解决方法，不论是技术、还是思想，都非常复杂，不管是商业的、有代码的，方方面面都考虑到了。想必很多程序员和我一样，学习 Web 程序开发的第一步，就是解决用户登录问题，在互联网不发达的情况下，都颇费周折，实现单点登录也和这差不多，不过绕了个圈子罢了。复杂的单点登录方法，往往都附加了很多与单点登录无关的职责，刨去这些无关的职责，就只是在一个地方进行用户登录的很小的应用系统。 轻量级单点登录系统的特性： l 轻量级； l 基于 Web-SSO 方案； l

修饰静态方法、实例方法、代码块 Synchronized修饰静态方法，对类对象进行加锁，是类锁。 Synchronized修饰实例方法，对方法所属对象进行加锁，是对象锁。 Synchronized修饰代码块时，对一段代码块进行加锁，是对象锁。 /** * synchronized示例 * 1、修饰静态方法 * 2、修饰实例方法 * 3、修饰代码块 */ public class SyncDemo2 { private static int num = 0; /** * 修饰静态方法 */ public static synchronized void count1() { for (int i = 0; i < 100000000; i++) { num++; } } /** * 修饰实例方法 */ public synchronized void count2() { for (int i = 0; i < 100000000; i++) { num++; } } /** * 修饰代码块 * 效果与修饰静态方法相同 */ public void count3() { synchronized(SyncDemo2.class) { for (int i = 0; i < 100000000; i++) { num++; } } } /** * 修饰代码块 * 效果与修饰实例方法相同

并发编程之线程第二篇 3.12 五种状态 3.13 六种状态 4.1 共享带来的问题 4.2 synchronized解决方案 4.4 变量的线程安全分析 4.6 Monitor概念 1. 轻量级锁 2. 锁膨胀 3.12 五种状态 这是从操作系统层面来描述的 【初始状态】仅是在语音层面创建了线程对象，还未与操作系统线程关联 【可运行状态】（就绪状态）指该线程已经被创建（与操作系统线程关联），可以由CPU调度执行 【运行状态】指获取了CPU时间片运行中的状态 （1）当CPU时间片用完，会从【运行状态】转换至【可运行状态】，会导致线程的上下文切换 【阻塞状态】 （1）如果调用了阻塞API，如BIO读写文件，这时该线程实际不会用到CPU，会导致线程上下文切换，进入【阻塞状态】 （2）等BIO操作完毕，会由操作系统唤醒阻塞的线程，转换至【可运行状态】 （3）与【可运行状态】的区别是，对【阻塞状态】的线程来说只要它们一直不唤醒，调度器就一直不会考虑调度它们 【终止状态】表示线程已经执行完毕，生命周期已经结束，不会再转换为其它状态 3.13 六种状态 这是从Java API层面来描述的 根据Thread.State枚举，分为六种状态 NEW 线程刚被创建，但是还没有调用start()方法 RUNNABLE 当调用了start()方法之后，注意，Java

OPCOL opcol一个开源的物联网系统，不依赖任何第三方平台，支持多种联网设备:WIFI、NB-IoT、4G、RJ45，支持微信小程序与手机APP - 服务器支持Windows,Linux,Mac 特性 支持搭建出完全私有物联网通信平台,可以运行内网也可以运行在互联网 完全开源 不依赖与任何第三方平台 支持基于JS语法的二次开发 在线DEMO演示 在线演示 文档介绍 安装使用 下载 https://gitee.com/imlsq/opcol 付费技术支持 微信/电话 18390966152 来源： CSDN 作者： imlsq 链接： https://blog.csdn.net/imlsq/article/details/104178832

写在前面 本文是作为阅读《深入理解Java虚拟机》第13章线程安全与锁优化的读书笔记； 线程安全是以多个线程之间存在共享对象为前提的。它并不是一个非黑即白的问题。Brian Goetz 曾就线程安全的“安全程度” 按以下由强至弱做了划分： 不可变；这类对象不需要进行任何线程安全的保障措施，只要这个对象被构建出来，其外部的可见状态永远也不会改变。如果共享数据是一个基本数据类型，那么只要在定义时使用 final 关键字修饰它，就可以保证它是不可变的。如果共享数据是一个对象类型，那就需要保证对象的行为不会对其状态产生任何影响才行，像 String 类的对象。 绝对线程安全；这类的划分的定义和不可变很像，但不可变更加的纯粹，简单。如果一个对象要是绝对线程安全的，那么需要保证多个线程中，对该对象的各种行为调用组合，都会得到想要的结果。举个例子来说， Vector 是线程安全的，但并不是绝对线程安全，比如，在一个线程对一定容量大小的 Vector 进行 remove 操作，另一线程进行 get 操作，最终，你会得到一个数组越界异常，这并不是我们想要的结果。其实，绝对线程安全是一种很苛刻的条件，所以，Java 中所讲的线程安全，通常指的是下面的相对线程安全。 相对线程安全；针对单个对象的单独操作是线程安全的。像上面 Vector 的 get 、remove 等操作。 线程兼容

Ninject通过NinjectModule来配置依赖注入（不知道有没有文件配置，在官方教程里没找到相关资料），这里自定义自己的Module： internal　class　MyModule　:　Ninject.Modules.NinjectModule　 {　 　　public　override　void　Load()　 　　{　 　　　　Bind<ILogger>().To<FlatFileLogger>();　 　　　　Bind<ILogger>().To<DatabaseLogger>();　 　　}　 } 　　具体调用方法： private　static　IKernel　kernel　=　new　StandardKernel(new　MyModule());　 static　void　Main(string[]　args)　 {　 　　ILogger　logger　=　kernel.Get<ILogger>();　 　　logger.Write("Bruce　Say:　Hello　Ninject!");　 　　Console.WriteLine("continues..");　 　　Console.Read();　 } 　　通过 kernel.Get<ILogger>() 来获取ILogger的实例，之前在MyModule里先后对ILogger

前言 前段时间看Mvc最佳实践时，认识了一个轻量级的IOC框架： Ninject 。通过google搜索发现它是一个开源项目，最新源代码地址是： http://github.com/enkari/ninject/tree/master 用户向导： http://ninject.codeplex.com/wikipage?title=User%20Guide&referringTitle=Home 建议新手请先看看Ninject的介绍： What Is Ninject Why Use Ninject 我节选其中关于Ninject的好处，并翻译如下： Ninject是一个快如闪电、超轻量级的基于.Net平台的依赖注入框架。它能够帮助你把应用程序分离成一个个松耦合、高内聚的模块，然后用一种灵活的方式组装起来。通过使用Ninject配套你的软件架构，那么代码将会变得更加容易编写、重用性强、易于测试和修改。 搜索博客园尚未找到关于Ninject的使用，因此本文发布一个示例作入门级教程。 Ninject入门级示例 像以前的IOC教程那样，拿日志记录做示例应该是非常直观的。 首先编写一个日志记录的接口： public interface ILogger { void Write(string message); } 以及 FlatFileLogger, DatabaseLogger

一.文件结构 ├　 index.php 入口文件 ├ class 类存放的文件夹 　　　├ base.class.php 基类 　　　├ error.class.php 错误处理类 　　　├ parms.class.php 获取参数类 ├ control.class.php 控制类 ├ model.class.php 模型类 ├ template smartTemplate 类存放文件夹 ├ db adodb 类存放文件夹 ├ includes 包含文件类 ├　 defines.inc.php 定义各路径文件 　　　├ frameword.inc.php 框架处理文件 　　　├ router.inc.php 路由文件 , 跟据参数 , 跳转不同路径 ├ models 模式存放路径 ├ views 模版文件保存路径 ├ controls 存放控制类的文件夹 ├ config.php 配置文件 ├ admin 后台 ├ ├ 二.简单类图 三. 入口文件 ,index.php <?php define("EXEC",1); //初始化一个常量,保存别的文件必须先有这个入口文件的引用. define('PATH_BASE',dirname(__FILE__)); //获取入口文件的路径 define('DS', DIRECTORY_SEPARATOR); //目录的分隔,’/’ 或’’

阿里云发布了国内首个公共云上的轻量级GPU异构计算产品——VGN5i实例，该实例打破了传统直通模式的局限，可以提供比单颗物理GPU更细粒度的服务，从而让客户以更低成本、更高弹性开展业务。适用于云游戏、VR/AR、AI推理和DL教学等轻量级GPU计算场景，更细粒度的GPU计算服务。 轻量级GPU云服务器是什么？ 轻量级GPU云服务器是一种新的GPU云服务器规格族，是通过公共云的GPU虚拟化技术将分片虚拟化后的GPU资源以虚拟GPU的形式安装在GPU云服务器实例中。与常规GPU云服务器的区别在轻量级GPU云服务器提供更细力度的GPU计算资源，比如拥有更少的CUDA计算核心，更小的显存。这样做的优势是在业务应用中，业务可以根据资源所需更加灵活的配置GPU计算资源。 用户在使用常规GPU云服务器的时候遇到了哪些痛点？ GPU的计算颗粒过大： 单颗物理GPU的计算能力越做越强大，但是许多应用需要更小颗粒的GPU计算资源； 常规GPU资源不利于业务自动伸缩： 拥有单颗物理GPU资源的实例在业务部署中会因为要充分利用GPU资源而造成“胖节点”，不利于设计成弹性伸缩架构，缺乏灵活性，无法应对业务快速变化； 常规GPU计算实例无法在线迁移： 常规直通虚拟化的GPU实例，由于架构特性无法支持GPU实例的在线迁移； 轻量级GPU云服务器与常规GPU云服务器有哪些不同？ 我们从GPU加速器呈现方式

vscode主要是轻量级，pycharm虽然笨重，但是各种功能都更完善一点。比如说代码补全，pycharm 的代码补全就比 vscode要完善、更全。 来源： https://www.cnblogs.com/hercules-chung/p/12247400.html