建武元年（1334年）11月13日、土佐国高岡郡津野（高知県高岡郡津野町）を支配していた豪族・津野氏の一族として生まれる。義堂周信とは同郷である。貞和4年/正平3年（1348年）に上洛して天竜寺に入った。観応元年/正平5年（1350年）に剃髪する。そして翌年に師匠である夢窓疎石が死去するまでは、その側に仕えたと言われる。夢窓疎石死後の文和2年/正平8年（1353年）に建仁寺の竜山徳見のもとへ赴き、同じく徳見の門下にあった義堂周信と共に教えを受けた。しかし翌年に竜山が南禅寺に移ったため、新たに赴任してきた大林善育のもとで教えを受け、そのもとで湯薬侍者を務めた。それから10年後の貞治3年/正平19年（1364年）に鎌倉へ赴き、そこで建長寺の青山慈永のもとに入った。そこでは蔵主・焼香侍者を務めた。翌年5月に同郷の周信が相模の善福寺に入院しようとしたときには、その衣鉢侍者を務めている。応安元年/正平23年（1368年）2月には明に渡海し、杭州の中天竺寺に入った。その後も霊隠寺、護聖万寿寺などに赴いて用貞輔良ら明の高僧らと出会い、これらの教えを受けた。洪武9年（1376年）には明の太祖である洪武帝（朱元璋）から謁見を許されている。洪武11年（1378年）に日本に帰国した。この明への渡海により、絶海中津は多くの高僧らと出会ったことで、俗的詩文の風と四六文の技法を身につけたと言われている。また、このような明への渡海は、かつての師匠である夢窓と同じく、日本における政治家や武将たちからも一目を置かれる存在として見なされるようになった。帰国後は天竜寺の性海霊見のもとに身を寄せ、康暦2年/天授6年（1380年）には建仁寺にいた義堂周信と再び会見する。同年、播磨守護として勢威を振るう赤松則祐より播磨法雲寺の住持として招聘されたが、絶海はこれを謝絶して則祐には汝霖良佐を推挙し、自らは甲斐慧林寺に赴任することにしたのである。永徳2年/弘和2年（1382年）に将軍・足利義満より上洛を命じられ、翌年9月に上洛する。義満は安聖寺（中陰道場）をどかせて鹿苑院を創建し、そこに絶海を住持として赴任させた。しかし中津は義満と次第に対立し、至徳元年/元中元年（1384年）6月に摂津に退去した。さらに義満の追跡を受けたため、翌年4月には有馬温泉にある牛隠庵に逃れている。しかし同年7月、細川頼之の招聘を受けて讃岐に渡り、そこで宝海寺を開いた。また、このときに師匠・疎石の遺跡といわれる土佐の吸江庵を再興している。至徳3年/元中3年（1386年）2月、義満は絶海を許した上で再びの上洛を命じる。同年3月に義満と謁見した絶海は、等持寺に入った。明徳2年/元中8年（1391年）には北山等持院に移り、翌年10月には相国寺住持となり、応永元年（1394年）には等持院に再び戻った。これら一連の激しい動きは、明徳の乱などの戦乱や義満との対立が原因とも言われている。応永元年9月に相国寺が焼失すると、その復旧に努めた。その功績から応永4年（1397年）2月に再び相国寺の住持として再任されるが、翌年には辞して鹿苑院院主となり、さらに僧録をも兼務し鹿苑僧録として五山や臨済宗寺院の統括を行った。応永6年（1399年）に起きた応永の乱においては、将軍義満に反旗を翻した大内義弘の陣へ義満の命を受けて説得に赴いている。応永11年（1404年）に辞して隠退し、応永12年（1405年）4月5日に死去した。享年72。
RTOSは通常マルチタスクOSで、スケジューリングはタスクの優先度に基づいて行われる。タスクの実行中（割り込みハンドラやOS自身などの実行中でないということ）は、常に、実行可能状態にあるタスクのうち最高優先度のものを実行しなければならない。実行中のタスクよりも優先度が高いタスクが実行可能状態になった場合は、即座にタスク切り替えを行う。すなわち、RTOSはいわゆる「プリエンプティブ・マルチタスク」（プリエンプションを参照）でなければならない。さらにRTOSの場合は、カーネルが優先度の低いタスクによるシステムコールを実行中の場合でクリティカルセクションでなければ、優先度の高いタスクを実行する「プリエンプティブ・カーネル」でなければならない。汎用OSのように、タスクの消費時間により優先度を変化させることは通常おこなわない。ただし、時間制約のない低優先度のタスクを複数同居させる場合など、それらのタスクでは優先度を共通とし、自発的にCPUを手放す協調的マルチタスクや、タイマ割込みにより順番に切り替えるタイムシェアリング的なスケジューリングを同居させることもある。典型的な設計では、タスクには「実行中」「実行可能」「ブロック」の3状態がある。ほとんどのタスクはブロック状態でいることが多い。CPUは1度に1つのタスクを実行できる（実行中状態となるタスクはCPU毎に最大1つ）。単純なシステムでは実行可能なタスクのリストも短く、せいぜい2個から3個のタスクが載っていることが多い。スケジューラの設計は重要である。実行可能タスクのリストはスケジューラのクリティカルセクション（プリエンプションが禁止され、場合によっては全割り込みも不可となる）で消費する時間を最小にするよう設計される。ただし、データ構造の選択は実行可能リスト上の最大タスク数にも依存する。実行可能リスト上のタスク数が少ないなら、単純な双方向線形リストが最適である。状況によって実行可能タスク数が増えるなら、優先度に従ってソートされたリストを使用し、最高優先度のタスクを探すためにリスト全体を検索する必要がないようにすべきである。そうすると、あるタスクを実行可能タスクのリストに追加する際にリスト全体を探索して、そのタスクより低い優先度のタスクを見つけ、その前の位置にタスクを追加（挿入）する必要が生じる。この探索期間中ずっとプリエンプションを禁止してはいけない。探索中の真にクリティカルな期間だけプリエンプションを禁止することで、例えば探索中に割り込みが発生してより高優先度のタスクが実行可能となったら、現に実行可能リストに挿入しようとしている低優先度タスクよりも先に実行可能リストに挿入して実行するようにしなければならない。新たな実行可能タスクをキューに登録し、最高優先度タスクの状態をリストアするのにかかる時間が非常に重要な応答時間である（フライバック時間とも呼ばれる）。よく設計されたRTOSでは、新たなタスクの実行可能キューへの挿入には（キュー上のエントリ毎に）3-20命令かかり、最高優先度タスクのリストアには5-30命令かかる。20MHzのMC68000プロセッサでは、2個のタスクが実行可能な状態でのタスク切り替え時間は20マイクロ秒である。100MHzのARMプロセッサでは数マイクロ秒となる。高度なリアルタイムシステムでは、リアルタイムのタスク以外に非リアルタイムタスクも共存するため、実行可能リストは非常に長くなる可能性がある。そのようなシステムでは、スケジューラの実行可能リストを単純な線形リストで実装するのでは不十分である。このため、優先度毎に実行可能リストを分割することで探索処理を不要にすることもある。